fdc7dece   
   From: pete@versatilecoding.com   
      
   On 2012-05-31 04:18:35 +0000, itaj sherman said:   
      
   > On May 30, 5:21 am, Pete Becker  wrote:   
   >> On 2012-05-30 00:39:27 +0000, itaj sherman said:   
   >>   
   >>> Right, it doesn't order x, I didn't mean for it to. The point was   
   >>> for x to cause a synchronization (an optional one) on the   
   >>> fences. So that stores that were sequenced before the release   
   >>> fence, be certainly visible to loads that happen after the acquire   
   >>> fence.   
   >>   
   >> That's not quite right. The fence causes the synchronization. But the   
   >> only way for the second thread to know that the synchronization has   
   >> occurred is to see the value that the first thread wrote into x. So   
   >> from a coding perspective, once you read the correct value, you know   
   >> that all the stuff that happened before the fence is visible in your   
   >> thread. If you haven't read the correct value it could simply because   
   >> the other thread hasn't gotten there yet.   
   >>   
   >   
   > Oh, I get what you mean, I only meant "x could imply synchronization"   
   > not "cause", by that the pair of store and load (which read the stored   
   > value) imply that the fences synchronize, per 29.8-p2   
   >   
      
   Sorry, I was a bit sloppy. The fence enforces visibility, which is what   
   I referred to as "synchronization". You used "synchronization" in a   
   higher-level sense, as in, ensuring that you've got visibility before   
   proceeding.   
      
   --   
    Pete   
      
      
         [ 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)