At 8:41 PM +1100 10/26/03, Sylvia Else wrote:
>Hi,
>
>Under the new JMM, one view of the purpose of synchronization is to
>allow the programmer to introduce an explicit happens-before
>relationship between actions that occur in different threads.
>
>However, it is quite heavyweight. It introduces that relationship
>for a vast array of actions for which it was never required. In
>practical terms, it can result in the flushing of memory caches, at
>considerable execution cost.
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.
Sun's 1.4 Hotspot server JVM is already compliant with the new
volatile specification (I believe the client JVM is as well, but I'm
not as confident). Try doing it with reading/writing a volatile each
time, and see if you are really getting any noticable performance
hit. I suspect you will not.
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:52 EDT