[concurrency-interest] Class striped/ordered Thread Pool

Kirk Pepperdine kirk at kodewerk.com
Sat May 12 14:50:26 EDT 2012


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 - The software stack for applications that scale
> 
> Twitter: @viktorklang
> 
> 
> 
> 
> -- 
> Viktor Klang
> 
> Akka Tech Lead
> Typesafe - 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/e83773f3/attachment-0001.html>


More information about the Concurrency-interest mailing list