Re: JavaMemoryModel: Cookbook: barriers

From: Alexander Terekhov (
Date: Mon Mar 17 2003 - 10:33:19 EST

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.


[...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).


JavaMemoryModel mailing list -

This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:42 EDT