[concurrency-interest] Curious: How Java Memory Model is satisfied in JSR166 locks?

Bill Pugh 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  
and swap)

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*

Bill




More information about the Concurrency-interest mailing list