title: Is function call an effective memory barrier for modern platforms?
body: <p>In a codebase I reviewed, I found the following idiom.</p>
  
  <pre><code>void notify(struct actor_t act) {
      write(act.pipe, "M", 1);
  }
  // thread A sending data to thread B
  void send(byte *data) {
      global.data = data;
      notify(threadB);
  }
  // in thread B event loop
  read(this.sock, &amp;cmd, 1);
  switch (cmd) {
      case 'M': use_data(global.data);break;
      ...
  }
  </code></pre>
  
  <p>"Hold it", I said to the author, a senior member of my team, "there's no memory barrier here! You don't guarantee that <code>global.data</code> will be flushed from the cache to main memory. If thread A and thread B will run in two different processors - this scheme might fail".</p>
  
  <p>The senior programmer grinned, and explained slowly, as if explaining his five years old boy how to tie his shoelaces: "Listen young boy, we've seen here many thread related bugs, in high load testing, and in real clients", he paused to scratch his longish beard, "but we've never had a bug with this idiom".</p>
  
  <p>"But, it says in the book..."</p>
  
  <p>"Quiet!", he hushed me promptly, "Maybe theoretically, it's not guaranteed, but in practice, the fact you used a function call is effectively a memory barrier. The compiler will not reorder the instruction <code>global.data = data</code>, since it can't know if anyone using it in the function call, and the x86 architecture will ensure that the other CPUs will see this piece of global data by the time thread B reads the command from the pipe. Rest assured, we have ample real world problems to worry about. We don't need to invest extra effort in bogus theoretical problems.</p>
  
  <p>"Rest assured my boy, in time you'll understand to separate the real problem from the I-need-to-get-a-PhD non-problems."</p>
  
  <p>Is he correct? Is that really a non-issue in practice (say x86, x64 and ARM)?</p>
  
  <p>It's against everything I learned, but he does have a long beard and a really smart looks!</p>
  
  <p>Extra points if you can show me a piece of code proving him wrong!</p>