[concurrency-interest] Class striped/ordered Thread Pool

Aleksey Shipilev aleksey.shipilev at gmail.com
Sat May 12 12:48:29 EDT 2012


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?

-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
>



More information about the Concurrency-interest mailing list