It is not clear to me that volatile and monitors should have the same
semantics when it comes to reorderings. The basic "roach motel" approach
with synchronized blocks works fine (so we've been persuaded :) ) because of
the added mutual exclusion. With volatiles there is no mutual exclusion and
I am concerned that these ordering rules may inhibit the use of volatile in
implementing various wait-free/non-blocking algorithms.
As an example, the optimistic readers transform of Strom and Auerbach (ref
ECOOP 2001) requires insertion of a dummy volatile read after a volatile
write to prevent subsequent non-volatile writes from being performed prior
to the volatile write. If volatiles are to be useful as flags in
wait-free/non-blocking algorithms then it seems to me that ordering is
critical and so volatile accesses should act as code motion barriers in both
directions.
It is also not clear to me whether the current proposal for volatile
enforces a total ordering on all volatile accesses as per the current
specification of volatile. Naturally this would just "fall out" of the
strong ordering semantics just mentioned.
David Holmes
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:32 EDT