[concurrency-interest] Class striped/ordered Thread Pool
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
>> 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.
> Concurrency-interest mailing list
> Concurrency-interest at cs.**oswego.edu <Concurrency-interest at cs.oswego.edu>
Akka Tech Lead
Typesafe <http://www.typesafe.com/> - The software stack for applications
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest