[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 
synchronization construct.

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
Skype: kabutz 

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 
>> always
>> 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.
> Gregg

More information about the Concurrency-interest mailing list