[My earlier reply bounced due to mailer issues.]
To expand on this a little, according to http://gee.cs.oswego.edu/dl/jmm/cookbook.html
the only architecture described there on which you don't need a memory barrier
AFTER a volatile store to deal with this issue is PA-RISC.
On IA-64, in general you need to implement a store to a volatile field with
st.rel ...
mf
The "st.rel" is needed to ensure that prior memory operations become visible before
the volatile write; the "mf" is needed to ensure that later volatile reads (implemented
with "ld.acq" cannot move to before the "st.rel". The "mf" can be omitted if another
volatile write follows before the next volatile read.
On X86 for example, the fence is also needed (and on many implementations slower),
though Java implementations will probably use an ordinary store before it.
None of this should slow down existing code much,
since there doesn't seem to be much existing use of "volatile".
This was discussed in detail, but alternatives
were found to be too obscure to use correctly.
Hans
> -----Original Message-----
> From: owner-javamemorymodel@cs.umd.edu
> [mailto:owner-javamemorymodel@cs.umd.edu]On Behalf Of Doug Lea
> Sent: Wednesday, March 24, 2004 4:02 PM
> To: Thomas Wang
> Cc: javamemorymodel@cs.umd.edu
> Subject: Re: JavaMemoryModel: Question about volatiles
>
>
> > Are there other platforms that can observe a memory value
> in its store
> > buffer without having it become globally visible?
>
> A "full" StoreLoad barrier is needed on all current processors to
> conform to JMM volatile write semantics, so IA64 isn't at a special
> disadvantage. There is room for exploiting special cases though, and
> in some of them a clever optimizer could instead use a st.rel here
> (which is an option that most other processors don't have).
>
> -Doug
>
> -------------------------------
> JavaMemoryModel mailing list -
> http://www.cs.umd.edu/~pugh/java/memoryModel
>
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:01:01 EDT