Bill Pugh wrote:
> 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.
The point I was trying to make was simply that nothing I was saying was
trying to preclude the removal of thread-local-volatile behaviour, nor any
other "optimisation" that might be foreseen.
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:33 EDT