The documentation is contradictory about what is the difference between volatile keyword and VH.setVolatile
I don't remember the chapter... but the one for VarHandle explicitly states that it resembled a fullFence... which means that at least both setVolatile and getVolatile are ofseq_cst barrier.
Now, I have my doubts that the keyword version is as strong.
The reason they are so obtuse about it is that within chapter 17 they attempt to try to explain both... the lock monitor and the volatile read/writes as if they were similar.
Chapter 17 treats the concept of "Synchronization order" out of nowhere.
It doesn't explain WHAT enforces it or how it even works under the hood.
I know by experience that the keyword is a lock-queue... so it being "totally ordered" is not true for MCS/CLH lock-queues which could very well work perfectly fine with both acquire and release semantics.
But anyways...
Chapter 17.4.3 makes a subtle distinction in my mind...
It states:
"A write to a volatile variable v (§8.3.1.4) synchronizes-with all subsequent reads of v by any thread (where "subsequent" is defined according to the synchronization order)"
Notice the property "synchronization order" is not explicitly granted to the "write to a volatile variable v" action/subject.
This means that the "total order property" that was previously granted to the "synchronization order" concept... is not the same as a volatile read/write as in the paragraph prior, in Chapter 17.4.2 it was implied that both where "synchronization actions"... not order.
17.4.2. Actions
An inter-thread action is an action performed by one thread that can be detected or directly influenced by another thread. There are several kinds of inter-thread action that a program may perform:
Read (normal, or non-volatile). Reading a variable.
Write (normal, or non-volatile). Writing a variable.
Synchronization actions, which are:
Volatile read. A volatile read of a variable.
Volatile write. A volatile write of a variable.
Then, in the next chapter, the "total order" property is given to the concept of "synchronization order"... but not actions.
17.4.3. Programs and Program Order
Among all the inter-thread actions performed by each thread t, the program order of t is a total order that reflects the order in which these actions would be performed according to the intra-thread semantics of t.
Which makes me guess... that what they are trying to talk about in this paragraph is about the synchronize keyword... aka the monitor/CLH queue.
In which case... YES... it behaves as a seq_cst barrier no doubt about that...
Now... going back to the first quote:
"A write to a volatile variable v (§8.3.1.4) synchronizes-with all subsequent reads of v by any thread (where "subsequent" is defined according to the synchronization order)"
The fact that the documentation uses the word "variable v" implies a monotonic-base sequencing defined by a "per-address sequential consistency", which... as far as I understand... is the BASE Program Order sequencing respected by ALL memory model/processors (bare metal) ... no matter how weak or strong they are.
And if any JIT or compiler disobeys this principle... then I recommend no one should be using that implementation anyways...
Based on the phrase "all subsequent reads of v" strongly implies that the barrier is anchored by the dependency chain of the address v (monotonic dependency chain).
Hence this is explicitly defined as a release since nonrelated ops on other addresses that are not v... are still allowed to be reordered before the release.
(To me) the usage of the word "v" is the hint that the volatile keyword is an acquire/release barrier.
If not... then the documentation needs to provide more explicit wording.
But this is not just a Java issue... even within the Linux Kernel... the concept of barriers/ fences and synchronization gets mixed up... so I don't blame them.