[concurrency-interest] LinkedTransferQueue in ForkJoinPool
Dr Heinz M. Kabutz
heinz at javaspecialists.eu
Thu Jan 12 07:49:10 EST 2012
On 1/12/12 2:27 PM, Doug Lea wrote:
> On 01/11/12 17:32, Dr Heinz M. Kabutz wrote:
>> On my Mac 1.7.0 build 223, the ForkJoinPool still contains a
> Sheesh. That was more than a year out of date even for JDK7. I hope
> that OpenJDK for OSX starts putting out regular releases soon.
Yes, I had my IDE pointing at the Java 7 sources from Jul 2011. My
mistake. However, we're not at 1.7.0_02 yet on the Mac. The bug in the
Random constructor is still there, causing ThreadLocalRandom to always
be seeded to zero. But I believe we'll be on the same release soon on
> The handling of pool submissions has always been a difficult
> engineering issue -- in classic ForkJoin use, one would expect
> relatively few external submissions that recursively decompose,
> which favors a low-overhead single array-based queue. However,
> it turns out that a lot of people are using them as "ForkPools"
> or plain ExecutorServices rather than ForkJoinPools, with tons
> of small non-recursive submissions. This often works OK as is,
> but can become highly contended (plus, is hostile to IO-bound tasks).
> So I'm now in the midst of replacing with a distributed
> random-multi-lane queue, and reworking stealing and scheduling
> to improve throughput in these and other cases.
> I'll post more about these upcoming changes as they get closer
> (hopefully soon). In the mean time, if anyone is using
> ForkJoinPools in this way and is feeling brave or curious,
> I've been putting snapshots of jsr166.jar
> at http://gee.cs.oswego.edu/dl/wwwtmp/jsr166.jar
> Placing this in -Xbootclasspath/p:jsr166.jar (plus possibly
> adding to CLASSPATH) replaces the j.u.c versions.
Very interesting, thanks :-)
More information about the Concurrency-interest