[jmm-dev] Specifying VarHandle acquire/release without ill effects

[Martin Buchholz]

With the proliferation of weakly ordered operations, our story on
happens-before and sequential consistency seems to have changed a little.
Our discussion on memory operations
http://download.java.net/java/jdk9/docs/api/java/util/concurrent/package-summary.html#MemoryVisibility
only discusses the happens-before relationship (a partial order), but the
memory operations being discussed (e.g. enqueueing and dequeueing from a
concurrent queue) actually satisfy a stronger condition - they are
sequentially consistent and form part of the global total order of all such
operations.  It would not be OK to have general purpose data structure
update and read operations to have only release/acquire memory order.

I'm hoping that our definition of "happens-before" will be as close as
possible to the C++ definition, for the sanity of the software industry.

On Sat, Jun 18, 2016 at 4:50 AM, Doug Lea <dl at cs.oswego.edu> wrote:

>
> But in the mean time, we should do something to improve wordings that
> Aleksey points out could mislead users and implementors in cases
> where acquire or release access is optimized away or weakened
> because it is thread-local, and so on. Minimally, we could add a
> disclaimer that enables at least those transformations and optimizations
> applying to volatiles.  Maybe just:
>
> The ordering constraints imposed by getAcquire and setRelease are weaker
> than, and  subsumed by those of getVolatile and setVolatile.