title: Behavior of memory barrier in Java
body: <p>After reading more blogs/articles etc, I am now really confused about the behavior of load/store before/after memory barrier.</p>
  
  <p>Following are 2 quotes from Doug Lea in one of his clarification article about JMM, which are both very straighforward:</p>
  
  <ol>
  <li><em>Anything that was visible to thread A when it writes to volatile field f becomes visible to thread B when it reads f.</em></li>
  <li><em>Note that it is important for both threads to access the same volatile variable in order to properly set up the happens-before relationship. It is not the case that everything visible to thread A when it writes volatile field f becomes visible to thread B after it reads volatile field g.</em></li>
  </ol>
  
  <p>But then when I looked into another <a href="http://mechanical-sympathy.blogspot.com/2011/07/memory-barriersfences.html">blog</a> about memory barrier, I got these:</p>
  
  <ol>
  <li><em>A store barrier, “sfence” instruction on x86, forces all store instructions prior to the barrier to happen before the barrier and have the store buffers flushed to cache for the CPU on which it is issued.</em></li>
  <li><em>A load barrier, “lfence” instruction on x86, forces all load instructions after the barrier to happen after the barrier and then wait on the load buffer to drain for that CPU.</em></li>
  </ol>
  
  <p>To me, Doug Lea's clarification is more strict than the other one: basically, it means if the load barrier and store barrier are on different monitors, the data consistency will not be guaranteed. But the later one means even if the barriers are on different monitors, the data consistency will be guaranteed. I am not sure if I understanding these 2 correctly and also I am not sure which of them is correct.</p>
  
  <p>Considering the following codes:</p>
  
  <pre><code>  public class MemoryBarrier {
      volatile int i = 1, j = 2;
      int x;
  
      public void write() {
        x = 14; //W01
        i = 3;  //W02
      }
  
      public void read1() {
        if (i == 3) {  //R11
          if (x == 14) //R12
            System.out.println("Foo");
          else
            System.out.println("Bar");
        }
      }
  
      public void read2() {
        if (j == 2) {  //R21
          if (x == 14) //R22
            System.out.println("Foo");
          else
            System.out.println("Bar");
        }
      }
    }
  </code></pre>
  
  <p>Let's say we have 1 write thread TW1 first call the MemoryBarrier's write() method, then we have 2 reader threads TR1 and TR2 call MemoryBarrier's read1() and read2() method.Consider this program run on CPU which does not preserve ordering (x86 DO preserve ordering for such cases which is not the case), according to memory model, there will be a StoreStore barrier (let's say SB1) between W01/W02, as well as 2 LoadLoad barrier between R11/R12 and R21/R22 (let's say RB1 and RB2).</p>
  
  <ol>
  <li>Since SB1 and RB1 are on same monitor <em>i</em>, so thread TR1 which calls <em>read1</em> should always see 14 on x, also "Foo" is always printed.</li>
  <li>SB1 and RB2 are on different monitors, if Doug Lea is correct, thread TR2 will not be guaranteed to see 14 on x, which means "Bar" may be printed occasionally. But if memory barrier runs like Martin Thompson described in the <a href="http://mechanical-sympathy.blogspot.com/2011/07/memory-barriersfences.html">blog</a>, the Store barrier will push all data to main memory and Load barrier will pull all data from main memory to cache/buffer, then TR2 will also be guaranteed to see 14 on x.</li>
  </ol>
  
  <p>I am not sure which one is correct, or both of them are but what Martin Thompson described is just for x86 architecture. JMM does not guarantee change to x is visible to TR2 but x86 implementation does.</p>
  
  <p>Thanks~</p>