Subj : Re: Memory visibility and MS Interlocked instructions
To   : comp.programming.threads
From : Alexander Terekhov
Date : Fri Aug 26 2005 03:09 pm


Joe Seigh wrote:
[...]
> Sun has #LoadLoad, #LoadStore, etc...  which gives you all the different
> memory ordering that you would need. 

Sun has a whole bunch of (compound) bidirectional fences. A subset 
of Sun's fences can be used to implement unidirectional hoist/sink 
stuff and also barrier(msync) intrinsic with "true == (msync & 
msync_rel) && (msync & msync_acq)" precondition  

  ssb|hsb -> StoreStore           // eieio or {lw}sync
  ssb|hlb -> StoreLoad            // sync
  slb|hsb -> LoadStore            // {lw}sync
  slb|hlb -> LoadLoad             // {lw}sync
  rel|hsb -> StoreStore+LoadStore // {lw}sync
  rel|hlb -> StoreLoad+LoadLoad   // sync
  ssb|acq -> StoreStore+StoreLoad // sync
  slb|acq -> LoadStore+LoadLoad   // {lw}sync
  rel|acq -> Sledgehammer proper  // sync

on Sun's hardware, but Sun's model sucks because bidirectional 
constraints are just way too heavy. As for cc/dd stuff, go read 
D.3.3. It says that cchsb (in somewaht dumb incarnation) is implied 
on Sparc hardware (for load{-modify-store} stuff) just like ddhlb, 
ddhsb, and ddacq (ddhlb+ddhsb). But cchlb does require a fence (in 
RMO): the same (trailing) MEMBAR #LoadLoad as ccacq (cchlb + cchsb). 

That does NOT mean that compilers can't be more effecient than 
Sun's hardware regarding reordering constraints (I mean compiler 
reordering).

regards,
alexander.

.