The many meanings of volatile read and write

Just a quick note on the topic as I find I keep having this conversation. Volatile fields in Java provide three distinct features:

1. Atomicity: volatile long and double fields are guaranteed to be atomically written. This is not the case otherwise for long double. See JLS section 17.7 for more details. Also see this excellent argument made by Shipilev on why all fields could be made atomic with no significant downside.
2. Store/Load to/from memory: a normal field load may get hoisted out of a loop and be done once, a volatile field is prevented from being optimized that way and will be loaded on each iteration. Similarly stores are to memory and will not be optimized.
3. Global Ordering: A volatile write acts as a StoreLoad barrier thus preventing previous stores from being reordered with following loads. A volatile read acts as a LoadLoad barrier and prevents following loads from happening before it. This is opposed to the meaning of volatile in C/C++ where only other volatile loads/stores are prevented from reordering.

I would personally prefer to have these more refined tools at my disposal for when I need them, but volatile is a 3-in-1 sort of tool...

What about AtomicLong.lazySet?

For those of you wondering (as I did) weather or not AtomicLong.lazySet (A.K.A Unsafe.putOrderedLong) provides atomicity, it would seem the answer is yes. Digging through the JVM source code for the putOrderedLong intrinsic yields the following nugget:

	bool LibraryCallKit::inline_unsafe_ordered_store(BasicType type) {
	// This is another variant of inline_unsafe_access, differing in
	// that it always issues store-store ("release") barrier and ensures
	// store-atomicity (which only matters for "long").
	/* ... all this unpleasant sea of nodes stuff ... not what I want to talk about ... */
	insert_mem_bar(Op_MemBarRelease);
	insert_mem_bar(Op_MemBarCPUOrder);
	// Ensure that the store is atomic for longs: <--- Yay!
	const bool require_atomic_access = true;
	Node* store;
	if (type == T_OBJECT) // reference stores need a store barrier.
	store = store_oop_to_unknown(control(), base, adr, adr_type, val, type, MemNode::release);
	else {
	store = store_to_memory(control(), adr, val, type, adr_type, MemNode::release, require_atomic_access);
	}
	insert_mem_bar(Op_MemBarCPUOrder);
	return true;
	}

view raw gistfile1.cpp hosted with ❤ by GitHub

Look at that perfectly pleasant C++ code! The store is indeed made atomic. We can further test this observation by looking at the generated assembly for a 32 vs 64 bit JVM:

	;A 64 bit JVM:
	mov QWORD PTR [rsi+0x118],rcx ;*invokevirtual putOrderedLong
	; - org.jctools.queues.InlinedCountersSpscConcurrentArrayQueue::tailLazySet@8 (line 131)
	; - org.jctools.queues.InlinedCountersSpscConcurrentArrayQueue::offer@83 (line 163)
	;A 32 bit JVM:
	vmovd xmm0,ecx
	vmovd xmm1,ebx
	vpunpckldq xmm0,xmm0,xmm1
	vmovsd QWORD PTR [esi+0x110],xmm0 ;*invokevirtual putOrderedLong
	; - org.jctools.queues.InlinedCountersSpscConcurrentArrayQueue::tailLazySet@8 (line 131)
	; - org.jctools.queues.InlinedCountersSpscConcurrentArrayQueue::offer@83 (line 163)

view raw gistfile1.asm hosted with ❤ by GitHub

There you go! Atomicity is perserved! Hoorah!