[jmm-dev] [pre-jmm9] Expressing ordering constraints

Doug Lea dl at cs.oswego.edu
Sat Feb 8 06:17:44 PST 2014


On 02/08/2014 02:11 AM, Hans Boehm wrote:
> I'm not sure where the proposal to add br;isync came from.

Me neither. Backing up ...

Because it would be vastly nicer in Java to equate semantics for
ordinary accesses to non-volatiles and relaxed accesses
to volatiles, I've been trying to further diagnose the basis
for the C/C++11 distinction and subsequent issues, to see
if we can avoid them. Hans's N3710
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3710.html)
includes some discussions, but I'm still missing some context
because this was introduced after I stopped paying close
attention to C/C++11 MM development.

As Hans mentioned, in C/C++ atomics are required to be coherent
even if accessed in relaxed mode. Coherence requires, among other
things that you don't see values "running backwards in time", which
might otherwise occur in reorderings such as { r1 = x; r2 = x; }.
When you mix this with current C/C++11 OOTA loopholes you encounter
inexplicable anomalies. (See examples in N3710 and others discovered
by Brian Demsky).

Ignoring the OOTA issue (that I suspect that we address in some other
way), the decision about requiring coherence regardless of
access mode seems suspicious. Is there a killer example of an
otherwise unprogrammable  algorithm? An otherwise unprovable property?

If not, my current sense is "Shrug; if you want ordering, ask for it".
At most we could support more ordering control methods.
(It looks like we will already be adding something like
dependentStoreFence(ref) to those in C/C++, and there's no
reason not to contemplate others.)

-Doug







More information about the jmm-dev mailing list