[concurrency-interest] Class striped/ordered Thread Pool

√iktor Ҡlang viktor.klang at gmail.com
Sat May 12 14:55:33 EDT 2012


Which question precisely?
On May 12, 2012 8:50 PM, "Kirk Pepperdine" <kirk at kodewerk.com> wrote:

> Queues are not about better performance for an individual thread. It's
> about parking (hence adding dead time) a thread until there are enough
> resources to service it. Which means I'd like to reask Aleksey's question.
>
> Regards,
> Kirk
>
> On 2012-05-12, at 6:58 PM, √iktor Ҡlang wrote:
>
> Also worth mentioning is that the map-queue approach does not need to do
> batch-execution, I only added that because it was trivial and usually gives
> better performance as it removes pressure from the submission queue of the
> "real" Executor.
>
> Cheers,
>>
> On Sat, May 12, 2012 at 6:53 PM, √iktor Ҡlang <viktor.klang at gmail.com>wrote:
>
>>
>>
>> On Sat, May 12, 2012 at 6:48 PM, Aleksey Shipilev <
>> aleksey.shipilev at gmail.com> wrote:
>>
>>> Yes, that is why I have general issue with solving this problem with
>>> map-queue designs. Why would one mess with shared state, instantiate
>>> queues per striped object, when tasks can just be multiplexed over
>>> single-threaded executors? OP did not forced the constraint for the
>>> tasks to be executed in a batch, there's only the constraint for
>>> same-class tasks to be executed in order. That is why I believe
>>> stateless design is better: it is much more fool-proof and as
>>> efficient. Is there something I miss there?
>>>
>>
>> A consistent-hashing approach as you described is a good one as well, the
>> problem is that when the stripes are unevenly distributed you end up with a
>> single threaded program.
>>
>> Cheers,
>>>>
>>
>>>
>>> -Aleksey.
>>>
>>> On Sat, May 12, 2012 at 8:43 PM, √iktor Ҡlang <viktor.klang at gmail.com>
>>> wrote:
>>> > And removing the ExecutionStripe as soon as it's done with existing
>>> > runnables might be a bad idea, and as soon as you involve a temporal
>>> aspect
>>> > like, fade to black after 10 seconds of idleness, you need to have a
>>> timer
>>> > running. An alternative is to try out Weak/Soft references, but that
>>> ain't a
>>> > walk in the park either...
>>> >
>>> > I apologize for the monologue, carry on....
>>> >
>>> > Cheers,
>>> > √
>>> >
>>> >
>>> > On Sat, May 12, 2012 at 4:05 PM, √iktor Ҡlang <viktor.klang at gmail.com>
>>> > wrote:
>>> >>
>>> >> Also, if you know when a stripe won't be used anymore, you can simply
>>> >> disassociate the stripe, and it will finish the tasks it was
>>> scheduled to
>>> >> run prior to becoming garbage collected.
>>> >>
>>> >>
>>> >> On Sat, May 12, 2012 at 3:23 PM, √iktor Ҡlang <viktor.klang at gmail.com
>>> >
>>> >> wrote:
>>> >>>
>>> >>>
>>> >>>
>>> >>> On Sat, May 12, 2012 at 2:47 PM, Aleksey Shipilev
>>> >>> <aleksey.shipilev at gmail.com> wrote:
>>> >>>>
>>> >>>> You seem to have pretty generic approach for making arbitrary
>>> executor
>>> >>>> look like striped one. I would be naturally to assume the number of
>>> >>>> stripes is arbitrary as well. ;) The race-free purges in these
>>> >>>> MultiMap-like cases is rather hard for inexperienced concurrency
>>> guys;
>>> >>>> much harder than writing the baseline map-queue-based
>>> implementation.
>>> >>>> That's why I think suggesting the baseline map-queue-based
>>> >>>> implementation and asking to fit purges there is like selling
>>> someone
>>> >>>> the house with a minefield in the yard.
>>> >>>>
>>> >>>
>>> >>> Shared mutable state concurrency IS a minefield. If you operate at
>>> that
>>> >>> level you need to learn how to disarm mines.
>>> >>> That's why I prefer to offer people things like composable futures
>>> and
>>> >>> actors instead of shared mutable state concurrency.
>>> >>>
>>> >>> Cheers,
>>> >>> √
>>> >>>
>>> >>>>
>>> >>>> -Aleksey.
>>> >>>>
>>> >>>> On Sat, May 12, 2012 at 4:35 PM, √iktor Ҡlang <
>>> viktor.klang at gmail.com>
>>> >>>> wrote:
>>> >>>> > It'll only be an issue if you have arbitrary stripes. Fixing that
>>> is a
>>> >>>> > great
>>> >>>> > exercise to the reader!
>>> >>>> >
>>> >>>> > Cheers,
>>> >>>> > V
>>> >>>> >
>>> >>>> > On May 12, 2012 1:55 PM, "Aleksey Shipilev"
>>> >>>> > <aleksey.shipilev at gmail.com>
>>> >>>> > wrote:
>>> >>>> >>
>>> >>>> >> On Sat, May 12, 2012 at 2:09 PM, √iktor Ҡlang
>>> >>>> >> <viktor.klang at gmail.com>
>>> >>>> >> wrote:
>>> >>>> >> > Here's an implementation I threw together (haven't been tested
>>> yet
>>> >>>> >> > so
>>> >>>> >> > YMMV)
>>> >>>> >> > that should make any Executor into a striped one, for every
>>> >>>> >> > runnable
>>> >>>> >> > that is
>>> >>>> >> > put in there which is Striped.
>>> >>>> >> >
>>> >>>> >> > https://gist.github.com/2665603
>>> >>>> >>
>>> >>>> >> Neat trick, but it is prone to memory leaks. You will have to
>>> protect
>>> >>>> >> yourself from multiple stripe classes come and go, that is,
>>> there is
>>> >>>> >> a
>>> >>>> >> garbage buildup in $stripes map, if some stripes are not being
>>> used
>>> >>>> >> (from some point, forever). Getting that right in race-free
>>> manner is
>>> >>>> >> tough.
>>> >>>> >>
>>> >>>> >> -Aleksey.
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>> --
>>> >>> Viktor Klang
>>> >>>
>>> >>> Akka Tech Lead
>>> >>> Typesafe - The software stack for applications that scale
>>> >>>
>>> >>> Twitter: @viktorklang
>>> >>>
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Viktor Klang
>>> >>
>>> >> Akka Tech Lead
>>> >> Typesafe - The software stack for applications that scale
>>> >>
>>> >> Twitter: @viktorklang
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > Viktor Klang
>>> >
>>> > Akka Tech Lead
>>> > Typesafe - The software stack for applications that scale
>>> >
>>> > Twitter: @viktorklang
>>> >
>>>
>>
>>
>>
>> --
>> Viktor Klang
>>
>> Akka Tech Lead
>> Typesafe <http://www.typesafe.com/> - The software stack for
>> applications that scale
>>
>> Twitter: @viktorklang
>>
>>
>
>
> --
> Viktor Klang
>
> Akka Tech Lead
> Typesafe <http://www.typesafe.com/> - The software stack for applications
> that scale
>
> Twitter: @viktorklang
>
>  _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120512/b97dc026/attachment.html>


More information about the Concurrency-interest mailing list