At 9:33 AM +1000 7/11/01, David Holmes wrote:
>I don't see any problem with allowing removal of thread-local volatiles. Any
>non-thread-local volatiles would then exhibit the one-way or two-way barrier
>behaviour (with acquire/release visibility semantics) as is being discussed.
There is a key and important difference.
One way to interpret what David is suggesting is to have the following rules
in the formal semantics:
* If a volatile variable is accessed by only a single thread, then
it is treated as a normal variable.
* Otherwise, it is treated as a one-way memory barrier.
This is very different from having acquire/release semantics.
Consider the following situation:
Thread 1 and 2 share a common volatile variable (taking turns
reading and writing it). Thread 3 and 4 share a different common
volatile variable. All four threads share access to normal variables.
We want to execute them on a cluster of SMP's that are running a
software DSM to provide an abstraction of a single shared memory
space across the entire cluster.
So these volatiles are not thread local.
Using acquire/release semantics, if we put thread 1 and 2 on the
same SMP node, and threads 3 and 4 on the same SMP node, then the
volatile memory accesses don't require us to execute any DSM
coherence actions, because the only threads that the volatiles are
communicating data to are on the same SMP node.
However, if you simply have a rule that thread local volatiles are
different, you would have to perform cluster-wide DSM coherence
actions.
I could come up with lots of other similar examples where you could
perform compiler transformations that could eliminate barriers
associated with non-thread-local acquire/release volatile variables.
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:33 EDT