I thought a little more and decided I was wrong about one of the
differences between the current JMM and Sarita's suggestion. I now
believe that the current JMM does prohibit reordering a read and a
following unlock. That gives us:
(Current JMM) You may not reorder:
+ A read and a following lock
* A lock and a following read
* A lock and a following write
* A read and a following unlock
* A write and a following unlock
Sarita's suggestion -- you may not reorder:
* A lock and a following read
* A lock and a following write
* A read and a following unlock
* A write and a following unlock
Sarita's suggestion is essential just release consistency (correct?).
So the only difference is that the current JMM doesn't allow you to
reorder a read and a following lock. Why do I believe this?
Assume you have a use followed by a lock. The spec says that assigns
and uses must happen in their original order. It doesn't include
locks and unlocks, but I am confident that it is just an omission;
without that rule, you can place a lock anywhere.
For each use, there must be a preceding load, and a read preceding
the load. So the read must precede the lock in main memory.
I don't see any reason why this would be useful, and doubt that there
is any reasonable Java code written that depends on this ordering
constraint. So I think we can drop it.
Bill
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:17 EDT