On Fri, 11 Aug 2023 02:33:05 GMT, chenggwang <d...@openjdk.org> wrote:
> Sorry, my description in Issue JDK-8314194(which I submitted) is ambiguous
> and makes you think of Phaser. My intention is that each generation of
> CyclicBarrier barrierCommand can change. Let me give you a scenario
> For example, the U.S. Army 'Gordon Sullivan Cup'.
> Five tanks competing.
> 1. The first round is for artillery strikes against targets.
> 2. Second round of anti-aircraft machine gun targets.
> 3. The third round is minefield racing.
> The scoring criteria are different for each round, so the CyclicBarrier's
> barrierCommand should be different for each round. But in the current code,
> `private final Runnable barrierCommand`, constructing the CyclicBarrier
> instance is already determined to be unchangeable.
As I wrote in the JBS issue and as Alan mentioned again above you can use the
single `BarrierAction` object to track the state changes and count the
generations/phase:
Runnable barrierAction = new Runnable() {
int phase = 0;
public void run() {
switch(phase++) {
case 0: doArtillery(); break;
case 1: doAntiAircraft(); nreak;
case 2: doMinefield(); break;
}
void doArtillery() { ... }
...
}
I do not believe there is sufficient justification for expanding the
`CyclicBarrier` API as proposed.
Happy to hear what @DougLea and @martin-buchholz think about this though.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/15239#issuecomment-1700472066
