At 10:41 AM 30/10/2003, Bill Pugh wrote:
I'm not sure I entirely understand the problem Sylvia believes exists.
>As others have mentioned, on x86, Sparc, and a number of other processors,
>no memory barriers are required for volatile reads (although barriers
>against compiler reorderings are required).
>
>It seems like what Sylvia wants is a kind of "non-urgent volatile": you
>want the right to be visible to other threads, but you don't care if it
>happens immediately. The JMM doesn't support any such operation. If you
>wanted to, you could do something where it only wrote/read a volatile once
>every 10 invocations, but I strongly double that would provide any advantage.
I accept that some of the current generation of processors do not impose
this cost - or to take a different view, they impose the cost for all
memory accesses, not just volatile ones.
Take a look at the Intanium architecture
http://developer.intel.com/design/itanium/manuals/245318.pdf
starting at page 399, MP Coherence and Synchronization.
On my reading, volatile references would have to use the acquire/release
forms of the instructions, whereas non-volatile references could use the
potentially faster unordered forms. It would appear that a program that
uses volatiles will incur extra costs in this architecture.
Sylvia.
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:52 EDT