[jmm-dev] Does a volatile load have to see the exact volatile store to synchronize?

[Brian Demsky]

Hi Hans,

Do you have an estimate of how much it would actually slow down Java on Power to implement the spec?  Or good reason to believe that code doesn’t rely on the specified behavior?

Brian

> On Apr 27, 2018, at 6:07 PM, Hans Boehm <boehm at acm.org> wrote:
> 
> [ This was previously posted to a smaller audience. Reposting here as the
> next step. ]
> 
> This seems to be a new Java memory model problem uncovered in response to
> the revision of "release sequences" in C++. wg21.link/P0982 has details.
> But if you don't care about the C++ memory model, you can ignore all that
> and just read the following.
> 
> Clearly this isn't the only or most serious open Java memory model problem.
> But I think it's actually one that has a fairly simple point solution. And
> it may be worth fixing without a comprehensive solution.
> 
> Problematic litmus test:
> 
> Writing =rlx for ordinary Java memory accesses and =sc for volatile ones,
> consider
> 
> Thread 1:
> x =plain 1;
> v =vol 1;
> 
> Thread 2:
> v =vol 2;
> 
> Thread 3:
> r1 =vol v;
> r2 =plain x;
> 
> Java disallows the final state, after joining all threads, of r1 = v = 2
> and r2 = 0. Since in the end v = 2, Thread 2s assignment to v must have
> followed Thread 1's  in the synchronization order. And in Java a volatile
> store synchronizes with all later (in synchronization order) volatile loads
> (Property A). This Thread 1 must synchronize with Thread 3, and r2 must be
> 1.
> 
> This diverges from the analogous C++ semantics. (The release sequence
> problem there is a bit different.)
> 
> The consensus of the experts in the other discussion is that this outcome
> is in fact allowed on Power, with both of the standard compilation models.
> Thus the spec and the implementations can't both be right in this regard.
> 
> IIRC, the JMM discussion that led to this, like the one that led to the
> vaguely analogous C++ problem, was more of a "why not" argument then
> anything solid. Which in retrospect was probably unwise in both cases.
> That, combined with the fact that this is a C++ vs Java divergence, and the
> expense of actually conforming to the current spec on Power, suggests we
> may want to call this a spec problem.
> 
> The concrete proposal would be to change the bullet (in 17.4.4)
> 
> * A write to a volatile variable v (§8.3.1.4) synchronizes-with all
> subsequent reads of v by any thread (where "subsequent" is defined
> according to the synchronization order).
> 
> to (for now)
> 
> * A write w to a volatile variable v (§8.3.1.4) synchronizes-with any read
> of v that observes the value written by w.
> 
> The reason I said "for now" is that I think we will eventually need
> C++-style "release sequences" in order to prevent intervening RMW
> operations from breaking the synchronizes with relationship here. Without
> that some fairly basic idioms, like reference counting, would look
> different in Java and C++, with Java being needlessly slower. But RMW
> operations aren't yet a thing in the JLS, so we can leave that in the
> bucket of other things that will eventually need fixing.
> 
> The argument for doing this now rather than later is that the spec clearly
> promises something that fails to hold for major implementations. And
> somewhat uniquely, in this case, we do know how to fix it. There is no
> reason to provide misleading information here.
> 
> Opinions?
> 
> Hans
>