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

[chenggwang]

On Wed, 30 Aug 2023 13:20:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > Hi Can anyone help me to review this PR @sormuras @asotona or any other reviewer?
> 
> I think you first need to make a case for changing the CyclicBarrier API as opposed to dealing with the phases in your BarrierAction or using the Phaser API.

Hi @AlanBateman，First thank you for coming to review, in this case use:
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.

It takes five threads to represent five tanks in a race,
① When all five threads reach the first Barrier, execute the first barrierCommand to score and rank the artillery firing.
② Then continue the second round of anti-aircraft machine gun competition, five threads have reached the second Barrier, and the anti-aircraft machine gun score is determined and ranked.
③ Finally, race in the tank minefield, reach the third Barrier, score and rank

The above three rounds only need to use one CyclicBarrier, because it can open the next generation at the end of each generation, so the CyclicBarrier can be reused, but the barrierCommand is final. Passing barrierCommand when a CyclicBarrier object is created through the constructor is an immutable object that cannot be used with a new barrierCommand every generation. But artillery attacks, anti-aircraft machine guns, minefield scoring rules are different, we need a variable barrierCommand

With the Phaser API, I'm not talking about using it. Instead, someone commented under my bugreport on using Phaser instead of CyclicBarrier. I mention Phaser here, feeling that it can dynamically add and subtract threads, but it doesn't fit my problem with this five-tank race

So you can ignore the phaser I mentioned and go all out to review the five tank races, each scoring criteria is different, that is, barrierCommand should be able to change, but the current version of barrierCommand is final and immutable

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

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