On Thu, 31 Aug 2023 10:02:45 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.
>
> Thank you @dholmes-ora @viktorklang-ora Your proposal is indeed a good
> solution! Enhancements and improvements became less urgent.
@chenggwang can you please close this PR and the associated Enhancement
request. Thanks
-------------
PR Comment: https://git.openjdk.org/jdk/pull/15239#issuecomment-1714854353
