[concurrency-interest] ThreadPoolExecutor workQueue concurrency issue

Guy Korland gkorland at gmail.com
Wed Dec 12 01:49:27 EST 2007


I suspected this is reason, in fact we saw this phenomena in another
internal concurrent data structure we developed, but weren't sure how to
resolve it.

  On Dec 12, 2007 2:33 AM, Doug Lea <dl at cs.oswego.edu> wrote:

> Guy Korland wrote:
> >
> > BTW, one small question can you explain the reason behind the
> > PaddeAtomicReference?
> >
> The Exchanger internal documentation has a better description
> of rationale -- see
> http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/Exchanger.java?view=log
> )
> But the main idea is that when you are spreading memory contention out
> from a single location, the last thing you want is to use
> to another location on the same cache line as the first --
> you'll get the same amount of memory contention. The padded
> versions just add some filler fields to avoid this. They lead
> to a very noticeable improvement on some machines, and are used
> sparingly enough that they don't noticeably impact footprint.
> -Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20071212/ed775650/attachment.html 

More information about the Concurrency-interest mailing list