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

[Jason T. Greene]

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 
> swap)
> 
> 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