Eliot Moss wrote:
>
> 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.
Yeah. Well, the cookbook says:
"....
On ia64, LoadStore, LoadLoad and StoreStore barriers are
folded into special forms of load and store instructions --
there aren't separate instructions. ld.acq acts as (load;
LoadLoad+LoadStore) and st.rel acts as (LoadStore+StoreStore;
store). Neither of these provide a StoreLoad barrier -- you
need a separate mf barrier instruction for that."
I guess that it could a-sort-of-"clarify" that reordering
restrictions mentioned above apply only to the following
"unordered"/"normal" memory accesses (in the program order;
on IA64; its "sequential pages" and "mf" aside):
- succeeding ones in the case of acquire
- preceding ones in the case of release.
Correct?
[...discussion about Java volatiles and "isync-WRT-CODE"...]
> I don't see what isync would have to do with normal data
> synchronization (though I could be missing something).
Please see the Book-E and the IBM paper about POWER4 sync.
(links can be found in the cookbook).
regards,
alexander.
-------------------------------
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