> -----Original Message-----
> From: owner-javamemorymodel@cs.umd.edu
> [mailto:owner-javamemorymodel@cs.umd.edu]On Behalf Of David F. Bacon
>
> 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.
Accesses to different volatiles require sequential consistency to be
enforced thus using atomic load/store ops to access them is only valid if
that sequential consistency is maintained. Given that many atomic ops have
no inherent memory barriers this implies that either memory barriers are
needed in addition to the atomic ops or else the use of atomic ops on the
architecture at hand acts as if memory barriers were used anyway. Thus
using memory barriers instead of atomic ops is at worst as expensive and at
best may be cheaper ;-)
For example I have been trying to establish exactly what happens when a CAS
is performed on SPARC under Total Store Ordering. CAS itself implies no
memory barriers but TSO says all stores are ordered - this seems to imply
that the store in the CAS is totally ordered wrt. other stores. If so CAS
acts a store barrier because all previous stores must complete before the
CAS store and the CAS store must complete before the CAS instruction
completes. Others had made measurements that seem to bear this out but
there is (as yet) no confirmation that this is how TSO + CAS is defined to
work.
Cheers,
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:23 EDT