From: terekhov@web.de   
      
   Marc wrote:   
   [...]   
   > > That's because under memory models like Itanium fences do not ensure   
   > > 'remote write atomicity' (cases with 3+ processors/threads).   
   >   
   > I would have thought that what the standard calls "atomic operations"   
   > already had the 'remote write atomicity' guarantee, couldn't be that   
   > simple :-)   
      
   It does if you use atomic_thread_fence(memory_order_seq_cst) fences or   
   use seq_cst labelled atomics.   
      
   [...]   
   > I am trying to see what the acquire does exactly in your code. It   
   > looks like it says: don't cleanup before setting the counter to 0, but   
   > then I don't see how that's related to mutability.   
      
   It says: don't read (for cleanup) before the counter is 0.   
      
   >   
   > > Decrements for reference counting under basic thread-safety can be   
   > > memory_order_relaxed with more relaxed fence than memory_order_release   
   > > for the case when resulting value of decrement != zero if referenced   
   > > counted object is immutable. I call such a fence "sink load barrier"   
   > > (release = "sink load barrier" + "sink store barrier").   
   >   
   > (trying to understand why this is the right answer and justifying it a   
   > posteriori)   
   >   
   > Hmm, I guess this barrier means: after decrementing the counter, it is   
   > too late to access the shared data . . .   
      
   Yes, it says: don't read after decrementing the counter.   
      
   regards,   
   alexander.   
      
      
   --   
         [ See http://www.gotw.ca/resources/clcm.htm for info about ]   
         [ comp.lang.c++.moderated.    First time posters: Do this! ]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)