First I should say that I have not gone through the latest memory model in
detail, but I _am_ familiar with the properties of the ia64 instructions.
Properties of _acquire_: An acquire prevents loads/stores issued AFTER the
acquire from being performed before the access associated with the
acquire. However, it does permit earlier issued loads/stores to be
performed after the acquire.
Properties of _release_: A release prevents loads/stores issued BEFORE the
release from being performed after the access associated with the
release. It does permit later issued loads/stores to be performed before
the release.
Clearly each of them is asymmetric. When used to bound a critical section
(synchronized region) they do serve to corral the accesses of the region
within the region. They do NOT prevent other accesses from wandering into
the region, though.
An implication is that if one tries to use ld.acq and st.rel to implement
sequentially consistent semantics for volatiles (I not claiming that that
is the semantics of the memory model, though it may be), then one needs a
stronger barrier between a st.rel and a succeeding ld.acq, because the
rules allow the ld.acq to be performed before a previously issued
st.rel. The opposite is not true; this is the only additional barrier
needed for sequentially consistent semantics of individual accesses.
Now as to isync on the PPC, its purpose is to deal with writing of CODE
that one might then begin to execute. This is necessary in (for example) a
Java GC that moves code around in the address space (or otherwise patches
code, or even generates code dynamically). In fact, the steps are to force
any dirty lines of the data cache to memory, do a sync (so that the
flushing has actually happened), drop corresponding lines from the
instruction cache (since they might contain stale copies), and finally do
an isync (to make sure they really have been dropped). I don't see what
isync would have to do with normal data synchronization (though I could be
missing something).
-- Eliot Moss
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:42 EDT