[concurrency-interest] Curious: How Java Memory Model is satisfied in JSR166 locks?
Jason T. Greene
jason.greene at redhat.com
Tue Aug 21 19:38:00 EDT 2007
Bill Pugh wrote:
> 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.
I was answering from a hardware context (mainly because hotspot was
mentioned), of how its possible that volatile access could/would affect
the visibility of other values in memory. Although I agree I should have
given more information and a proper link to the JMM.
> 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
> There is nothing that make it impossible/difficult/wrong for special
> methods, defined by the JVM, to establish happens-before orderings.
Yes not wrong, just slow ;)
> 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*
Agreed, although I find that many people are interested in some of the
details, especially when they are thinking about performance. As far as
documentation goes, I think concurrent has done an exceptional job.
Jason T. Greene
Lead, POJO Cache
JBoss, a division of Red Hat
More information about the Concurrency-interest