[concurrency-interest] Class striped/ordered Thread Pool

√iktor Ҡlang viktor.klang at gmail.com
Sun May 13 07:33:06 EDT 2012

On Sun, May 13, 2012 at 1:10 PM, Doug Lea <dl at cs.oswego.edu> wrote:

> On 05/12/12 14:29, √iktor Ҡlang wrote:
>> Well, the entire point is to have stripes serialized, isn't it. The
>> problem is
>> that the consistent-hashing approach will make execution serial for all
>> stripes
>> that hash the same. Which is slightly different.
> If it were not for the per-producer-fifo constraint, this could
> be solved by using incremental table expansion and self-adjusting
> hashes, as is done in Striped64 (LongAdder etc) as well as new
> Exchanger and FJ submission queues.
> It is possible but not easy, and probably not fast enough,
> to adapt this to preserve fifo by tracking whether any thread
> has unclaimed elements, and if so, inhibiting its hash adjustment.

I've started to strip down the most current CLQ to see what can be gained
from not supporting non-head deletes etc.

One of the issues here is that we're talking so fast operations taht doing
anything to gain speed might just end up costing more, as you say.


> -Doug
> ______________________________**_________________
> 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>

Viktor Klang

Akka Tech Lead
Typesafe <http://www.typesafe.com/> - The software stack for applications
that scale

Twitter: @viktorklang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120513/4ad99712/attachment.html>

More information about the Concurrency-interest mailing list