[concurrency-interest] Class striped/ordered Thread Pool
Dr Heinz M. Kabutz
heinz at javaspecialists.eu
Sat Nov 17 12:34:34 EST 2012
For those of you who might be interested, here is a writeup of the
StripedExecutorService that we discussed in May. I've also added an
explanation of how the SerialExecutor works, which took a few brain
cycles on my side to figure out.
Surprisingly, the newsletter produced a fair amount of good feedback.
It seems that others have also encountered a need for this type of
I did some cursory performance testing last week to see how it compares
against, for example, a fixed thread pool. As I expected, it is not
very fast. I've had some ideas of how to fix this, for example, by
introducing a "poison pill" approach to shutting down. Writing a faster
StripedExecutorService would be trivial if it weren't for lifecycle
management. We need to ensure that no job remains in the queues after
shutdownNow() has been invoked, for example. If any of you are keen to
cooperate on writing a non-blocking version of this class and to then
donate that to the greater good of mankind, please contact me off-list.
Dr Heinz M. Kabutz (PhD CompSci)
Author of "The Java(tm) Specialists' Newsletter"
Sun Java Champion
IEEE Certified Software Development Professional
Tel: +30 69 75 595 262
On 5/16/12 3:10 PM, Gregg Wonderly wrote:
> On 5/16/2012 3:16 AM, Dr Heinz M. Kabutz wrote:
>> I've spent yesterday and part of today looking at various approaches
>> to solve
>> this problem.
>> 1. My idea of a striped queue would not work, because tasks are not
>> enqueued before they are handed off to workers.
>> 2. I've got a nice solution utilizing the SerialExecutor approach,
>> however, as
>> Joe mentioned, shutdown is particularly challenging. I'm still trying
>> to solve
>> that, but it is not easy.
>> 3. Another challenge, also mentioned already in this thread, is that
>> we need to
>> carefully manage the map so that we do not get a memory leak. The
>> solution I'm
>> trying now is to delete the SerialExecutor from the map whenever it
>> is empty.
>> This might create a lot of objects, but at least we don't have to
>> worry about a
>> memory leak.
> This is precisely the type of place where I use a counter to manage
> lifecycle beginning and end. Code needs to be completely correct,
> before it is "completely efficient". I've rarely ever had to decide
> to start optimizing these kinds of places once I have things up and
> running and do some instrumentation. Rarely, are these the hot spots
> for latency injection.
More information about the Concurrency-interest