> Does anyone see any problem in this reasoning? If not, the memory
> model should support it.
i see now what you are getting at. and if loads of volatiles were implemented
with read barriers, then it would work.
however, a major optimization that can normally be performed on volatiles is to
implement them using atomic load/store ops, and not doing any memory barriers.
i think it would be a mistake to take the only form of synchronization in java
that is not global in nature, and force it to be global.
this is particularly true because java does not guarantee atomicity for
long/double unless they are decalred volatile.
> Because JLS does not talk explicitly about read barriers wrt
> volatiles, it doesn't quite say that this will happen, but it does
> happen.
well, in truth volatiles simply aren't implemented properly by most JVMs. so
it's not clear what "does happen".
i suppose you could say without too much harm that using volatile array
references forces a read barrier, but then you're just overloading the volatile
keyword with two separate meanings. once again, more deep subtlety in the
memory model that almost no one will understand. but if there's no other way
to get multiple reader parallelism, maybe it's worth it, since most people will
just percieve it as a slowdown of array volatiles on weakly ordered MPs --
thankfully not a common situation.
david
-------------------------------
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