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

[Hans Boehm]

I'm not sure where the proposal to add br;isync came from.  I think BMM would require that, but that seems more drastic than what I've seen proposed here.  Even the N3710 ld->st ordering proposal is believed to require at most the branch without the isync.  (And, if adopted, I would expect that branch to be replaced by another instruction that doesn't consume branch prediction slots in a few years.)

Hans

--------------------------------------------
On Fri, 2/7/14, Paul E. McKenney <paulmck at linux.vnet.ibm.com> wrote:

 Subject: Re: [pre-jmm9] Expressing ordering constraints
 To: "Doug Lea" <dl at cs.oswego.edu>
 Cc: "pre-jmm9 at cs.oswego.edu" <pre-jmm9 at cs.oswego.edu>, "Boehm, Hans" <hans.boehm at hp.com>
 Date: Friday, February 7, 2014, 10:46 AM
 
 On Sat, Feb 01, 2014 at
 10:16:34AM -0500, Doug Lea wrote:
 > On
 01/30/2014 01:30 AM, Boehm, Hans wrote:
 >
 
 > >You mean that you would prefer
 intentionally racy but unordered accesses
 > >have the same semantics as data
 not-intended-to-be-racy accesses? ... The
 > >feeling on the C++ committee,
 particularly on Paul's part, IIRC, was that we
 > >did want coherence for the
 intentionally racy accesses, because its absence
 > >was just too horrible to deal with.
 > 
 > This might be one of
 my rare disagreements with Paul. In this case,
 > simplicity of rules seems worth the extra
 agony for people who can
 > figure out how
 to cope if they need to.  Without distinguishing these,
 > the parts of the JMM that most programmers
 would ever need to deal
 > with might look
 like something like the following. It's not quite
 > as simple as, say, BMM, but seems to be on
 the right track:
 
 It is not
 just me.  
 
 The possibility
 of adding compare-branch-isb/isync to C11 relaxed loads
 came up on the Linux kernel mailing list today,
 and the reaction of one
 prominent maintainer
 was, and I quote, "sounds like someone took a big
 toke from the bong again."  One of the
 ARM64 maintainers took a somewhat
 less
 colorful but equally negative position, questioning why
 additional
 otherwise-unnecessary
 instructions were being contemplated to solve what
 he termed a compiler problem.
 
 The Linux-kernel discussion
 was of course C11 rather than Java, but
 nevertheless, just saying...