Is JCStress sample test Classic_01_DiningPhilosophers.Arbitrator correct?

[Aleksey Shipilev]

On 7/19/22 05:20, Serguei Katkov wrote:
> I'm trying to figure out what guarantees that release forks (setting false to elements of forks 
> array) is visible for other threads?
> 
> Say p1 implements the last iteration in stride, sets true to forks[0] & forks[1], release waiter 
> monitor (since this moment p2, p3 after taking waiter monitor must see an update of forks to true) 
> leaves infinite loop and restore elements to false without any synchronization and goes in framework 
> for sync with other threads using access to other volatile variable.
> 
> So why must p2 and p3 see false value in forks[0] and forks [1]?
> Without that p2 and p3 fall into an infinite loop.

This touches on "progress guarantees", see e.g. BasicJMM_04_Progress sample.

Formally, there are not progress guarantees here, indeed. That's a formal bug to be fixed, because 
samples should be targeting the formal guarantees.

Implementation-wise, most (all?) hardware would make the writes of forks[0..1] = false visible to 
readers eventually. The synchronized(writer) thing on "reader" side breaks potential load commonning 
that would otherwise allow compilers to hoist the read out of the loop.

See this PR:
   https://github.com/openjdk/jcstress/pull/117

-- 
Thanks,
-Aleksey