title: Memory Model: preventing store-release and load-acquire reordering
body: <p>It is known that, unlike Java's volatiles, .NET's ones allow reordering of volatile writes with the following volatile reads from another location. When it is a problem   <code>MemoryBarier</code> is recommended to be placed between them, or <code>Interlocked.Exchange</code> can be used instead of  volatile write.  </p>
  
  <p>It works but <code>MemoryBarier</code> could be a performance killer when used in  highly optimized lock-free code. </p>
  
  <p>I thought about it a bit and came with an idea. I want somebody  to tell me if I took the right way.</p>
  
  <p>So, the idea is the following:</p>
  
  <p>We want to prevent reordering between these two accesses:</p>
  
  <pre><code> volatile1 write
  
   volatile2 read
  </code></pre>
  
  <p>From .NET  MM we know that : </p>
  
  <pre><code> 1) writes to a variable cannot be reordered with  a  following read from 
      the same variable
   2) no volatile accesses can be eliminated
   3) no memory accesses can be reordered with a previous volatile read 
  </code></pre>
  
  <p>To prevent unwanted reordering between  write and read we introduce a dummy volatile read from the variable we've just written to:</p>
  
  <pre><code> A) volatile1 write
   B) volatile1 read [to a visible (accessible | potentially shared) location]
   C) volatile2 read
  </code></pre>
  
  <p>In such case <strong>B</strong> cannot be reordered with <strong>A</strong> as they both access the same variable,
  <strong>C</strong> cannot be reordered with <strong>B</strong> because two volatile reads cannot be reordered with each other, and  transitively <strong>C</strong> cannot be reordered with  <strong>A</strong>.</p>
  
  <p>And the question: </p>
  
  <p>Am I right? Can that  dummy volatile read be used as a lightweight memory barrier for such scenario?</p>