RFR: JDK-8314194: Reusing CyclicBarrier, it should be possible to change the barrierCommand

[Viktor Klang]

On Thu, 31 Aug 2023 06:59:29 GMT, David Holmes <dholmes at 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.

I agree with @dholmes-ora — the transition is in/belongs to the action, not the barrier.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15239#issuecomment-1700503736