[concurrency-interest] Class striped/ordered Thread Pool

Jitendra Chittoda jcchittoda at gmail.com
Sun Nov 18 11:42:34 EST 2012

Hi Dr Heinz,

I had been developing same concept since last year and still in
development. Meanwhile I am also writing a paper on the same with
the various implementation modes.

You can see my blog on this and an open source project.

Though the "koncurrent" project code might not be in running state as it is
under R&D state. But I would make it in workable mode asap.

I am having plans to complete this along with the non-blocking version so
that we can put a new JSR request to have it included in java concurrency.

We can have some discussions off-list, and I would be interested in sharing
my stuff with you.

Thanks & Regards,
Jitendra Chittoda

On Sat, Nov 17, 2012 at 11:04 PM, Dr Heinz M. Kabutz <
heinz at javaspecialists.eu> wrote:

> 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.
> http://www.javaspecialists.eu/**archive/Issue206.html<http://www.javaspecialists.eu/archive/Issue206.html>
> 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.
> Regards
> Heinz
> --
> Dr Heinz M. Kabutz (PhD CompSci)
> Author of "The Java(tm) Specialists' Newsletter"
> Sun Java Champion
> IEEE Certified Software Development Professional
> http://www.javaspecialists.eu
> 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
>>  ______________________________**_________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.**oswego.edu <Concurrency-interest at cs.oswego.edu>
> http://cs.oswego.edu/mailman/**listinfo/concurrency-interest<http://cs.oswego.edu/mailman/listinfo/concurrency-interest>

Thanks & Regards,
Jitendra Chittoda
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20121118/a75d33bb/attachment.html>

More information about the Concurrency-interest mailing list