RFR: JDK-8074578 Document memory visibility effects of some Unsafe methods

[David Holmes]

On 10/03/2015 3:04 PM, Martin Buchholz wrote:
> ??
> I mentally map Java volatile operations to C11 seq_cst because of the
> total order over all operations on volatile variables.
> Volatile reads and writes do not just have acquire/release semantics.

You may be right. The synchronization order (not just operations on 
volatiles) is a total order. I tend to only think about the 
acquire/release semantics of volatile accesses - or more specifically 
the allowed reorderings with respect to other stores and loads. I 
confess I don't know what having a total order requires beyond the 
barriers we utilize for the volatile read/write actions ?? The fact we 
have two different orderings in C11 suggests something extra is required 
by the implementation to achieve seq_cst.

David

> The java memory model does not (yet) have C11-style relaxed atomics
> (like acquire or release)
>
> On Mon, Mar 9, 2015 at 6:38 PM, David Holmes <david.holmes at oracle.com
> <mailto:david.holmes at oracle.com>> wrote:
>
>     PS. You state: "Corresponds to C11
>     atomic_compare_exchange___strong." Yet that would match with the
>     full bi-directional fences of the VM implementation (due to
>     memory_order_seq_cst), not a volatile read followed by a volatile
>     write (which would be memory_order_acq_rel).
>