Set your Java 7 Phasers to stun
Saw a very interesting note today from Doug Lea on the concurrency-interest mailing list. Looks like they are extracting a useful internal part of the fork-join framework and making it available in java.util.concurrent as a new Phaser class.
The concurrency-interest archives aren’t open so I’ve taken the liberty of reproducing Doug’s email here:
Date: Mon, 07 Jul 2008 13:19:01 -0400
From: Doug Lea
Subject: [concurrency-interest] Phasers (were: TaskBarriers)
To: concurrency-interest@cs.oswego.edu
The flexible barrier functionality that was previously restricted to ForkJoinTasks (in class forkjoin.TaskBarrier) is being redone as class Phaser (targeted for j.u.c, not j.u.c.forkjoin), that
can be applied in all kinds of tasks. For a snapshot of API, see http://gee.cs.oswego.edu/dl/jsr166/dist/jsr166ydocs/jsr166y/Phaser.html
Comments and suggestions are very welcome as always. The API is likely to change a bit as we scope out further uses, and also, hopefully, stumble upon some better method names.
Among its capabilities is allowing the number of parties in a barrier to vary dynamically, which CyclicBarrier doesn’t and can’t support, but people regularly ask for.
The nice new class name is due to Vivek Sarkar. For a preview of some likely follow-ons (mainly, new kinds of FJ tasks that can register in various modes for Phasers, partially in support of analogous X10 functionality), see the paper by Vivek and others:
http://www.cs.rice.edu/~vsarkar/PDF/SPSS08-phasers.pdf
-Doug
I use CyclicBarrier all the time and could definitely use some of the new Phaser features. In addition to the existing CyclicBarrier functionality (reusable, barrier actions), Phaser has these features:
- Party count can change dynamically
- Each phase has an incrementing phase number associated
- Termination state (where await actions immediately return)
- Exceptions during waiting do not change barrier state
In CyclicBarrier, the barrier action is implemented by providing a Runnable. In Phaser, barrier actions are implemented by subclassing Phaser and overriding onAdvance(), which gives you easy access to the state of the Phaser. The method itself receives the current phase count and number of currently registered parties. I don’t like the reliance on inheritance here – the CyclicBarrier approach to using an external task is far preferable in my mind.
In any case, it’s awesome to see this work becoming more available. You can, by the way, compile and use the jsr166y library on older JDKs (including the fork-join library), so if you need some Phaser action, you could use it now (with the caveat that it’s a work in progress) without waiting for Java 7 (when you will probably be retired).
Hi! My name is Alex Miller and I live in St. Louis. I write code for a living and currently work for 
hi alex,
“without waiting for Java 7 (when you will probably be retired). ”
are you serious ? I thought it will be out in beta form mid 2009 ?
Thank you,
BR,
~A
Not too serious. :) At this point, there is no JSR for Java 7. I won’t believe any date until an expert group actually decides what will be included in it. I think you’re dreaming to believe it will be out in any final-ish form in early 2009. I’d say late 2009 is a more likely plan (if that’s even achievable).
Of course, you can go grab the bits now if you want so in some sense it’s already out. :)
hi alex,
I joined the concurrent mailing list and requested if a public archive was available and Doug made it public : http://altair.cs.oswego.edu/pipermail/concurrency-interest/
:-)
BR,
~A
Awesomesauce.
Question: I have an application that will have an unknown amount of threads starting (loading an MLet file) but I would like them to do their initialization and then wait before continuing. Both CountDown and Cyclic require you to know the number of threads being started. Currently I have them waiting on a common lock and then let them continue. This seems like a hack to me. An ideas of a better way?
Thanks
-Pete