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

[Martin Buchholz]

On Fri, 11 Aug 2023 02:33:05 GMT, chenggwang <duke 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.

We should try to retain designed immutability in concurrency classes.
Having had the experience of having fixed many bugs with knobs tunable at runtime.
If you make a field mutable, you need to think not just about "set", but also about "compare and set", "freeze" and security implications of adding a new form of attack.

So let's leave CyclicBarrier unchanged.

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

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