> so i think you can implement volatiles this way, even if they must be
> sequentially consistent with respect to each other. or am i missing something
> else?
At least some of us seem to have different interpretations and
assumptions about volatile.
I think your no-barrier form of volatile is legal in JLS version, and
might be consistent with Bill's main October 22 posting on LC model
(http://www.cs.umd.edu/~pugh/java/memoryModel/archive/0250.html). But
Bill's, Paul's and other people's subsequent postings (for example
http://www.cs.umd.edu/~pugh/java/memoryModel/archive/0238.html)
clearly assume/require a barrier, at least when there are any writes.
Others posts (especially by me!) have been less consistent.
To forestall more confusion, we probably ought to agree on
at least names for different concrete proposals before
discussing merits.
While I'm at it, here is what I think is a very simple proposal
that might hit the right compromise:
volatile == synchronized minus locking
A read of any volatile field v of any object x is equivalent to
synchronized(x) { localv = v; }
And similarly for write
synchronized(x) { v = localv; }
EXCEPT that
* no locks are acquired or released.
* reads/writes of 64bit volatile fields are atomic.
Where the rules for entry/exit are as in Bill's LC proposal. (In
fact, you could apply this proposal to any entry/exit rules.)
This leads to barriers, but not so many of them. It does NOT
guarantee full SC of programs solely employing volatile fields,
but probably does so in all cases of practical interest.
-Doug
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:23 EDT