[concurrency-interest] Curious: How Java Memory Model is satisfied in JSR166 locks?
pugh at cs.umd.edu
Tue Aug 21 18:49:48 EDT 2007
Don't use the term "memory barrier" in the Java context.
Nothing in Java establishing a memory barrier. Thinking of memory
barriers in Java can lead you down a bad path.
Various operations establish a happens-before ordering:
* from an unlock on a monitor to a later lock of the same monitor
* from a volatile write to a later volatile read of the same field
* from an update to a later read of an atomic field (e.g., compare
There is nothing that make it impossible/difficult/wrong for special
methods, defined by the JVM, to establish happens-before orderings.
From the viewpoint of the user of a library, you don't care whether
a happens-before ordering is established, just that it is. Having
consistent documentation of which pairs of operations establish
happens-before orderings would be a good thing, and an attempt to
provide that documentation has been made for java.util.concurrent*
More information about the Concurrency-interest