[concurrency-interest] Ordering Question

Justin Sampson jsampson at guidewire.com
Thu Jul 21 15:02:22 EDT 2016

This is a recurring question -- there was a thread 2 years ago about it:


This was my contribution:

"My own _guess_ based on the docs is that a full-volatile write ensures a
happens-before relation with _all_ subsequent volatile reads of the same
field, whereas a lazy/ordered write ensures a happens-before relation
with any subsequent volatile read _that sees the value written_ by that
write.  Therefore lazy writes guarantee, for example, safe publication
of objects, without actually forcing everything immediately out to main
memory.  But all bets are off, of course, if the read itself is not a
volatile read."


-----Original Message-----
From: Concurrency-interest [mailto:concurrency-interest-bounces at cs.oswego.edu] On Behalf Of Aleksey Shipilev
Sent: Wednesday, July 20, 2016 2:56 AM
To: Alex Otenko
Cc: concurrency-interest
Subject: Re: [concurrency-interest] Ordering Question

On 07/20/2016 12:48 PM, Alex Otenko wrote:
>> If X = 1 is a putOrdered/lazySet/release store, then total 
>> synchronization order is out of the picture. It is actually hard
>> to reason about the acq/rel outcomes in the realm of plain JMM, but
>> here is a try. release-acquire brings a happens-before. Let's see
>> if we can construct a plausible execution that reads (0, 0) and is
>> consistent with JMM.
> Since hb for putOrdered/laziSet aren’t specified in JMM, can you show
> which happens-before is brought by release-acquire here? (Or in
> general which ones are introduced? I have an idea what that might
> relate to, but need a rubber-stamped statement)

putOrdered/lazySet/release are not defined in JMM, so there is no
possibility for a rubber-stamped statement. I am using the closest
interpretation that is consistent with it's effect I can come by:
release-acquire brings happens-before, but not synchronization order.

See e.g. here:


More information about the Concurrency-interest mailing list