[concurrency-interest] ThreadPoolExecutor workQueue concurrency issue

Guy Korland gkorland at gmail.com
Tue Dec 11 15:57:32 EST 2007


Thanks for the hint, I'll try it ASAP.
BTW, one small question can you explain the reason behind the
PaddeAtomicReference?

Guy

On Dec 11, 2007 1:23 PM, Doug Lea <dl at cs.oswego.edu> wrote:

> Guy Korland wrote:
> > Hi,
> > We built an application in a SEDA fashion, working in stages from one
> > ThreadPool to another.
> > We found out that the BlockingQueue used by the ThreadPoolExecutor
> > became a major concurrency killer when we start working on 4 cores
> > machines and above.
> > The thing is that we don't really need the strong FIFO behavior forced
> > by all the BlockingQueue implementations available, some kind of
> > fairness will be good enough.
> > Any ideas?
> >
>
> You might consider trying LinkedTransferQueue that is out
> in preliminary form in jsr166y. It eases up guarantees
> to merely promise FIFOness wrt any given producer. Internally,
> it extends some of the ideas from the java6 overhaul of
> SynchronousQueue, and tends to have better throughput
> under contention than LinkedBlockingQueue. In other words,
> it was designed exactly to solve the problems you are seeing.
> Javadoc at:
> http://gee.cs.oswego.edu/dl/jsr166/dist/jsr166ydocs/
> It is available in the jar for jsr166y listed at
> http://gee.cs.oswego.edu/dl/concurrency-interest/index.html
>
>
> -Doug
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20071211/c87f03db/attachment.html 


More information about the Concurrency-interest mailing list