title: Does a pthread_cond_signal or pthread_cond_broadcast call imply a write memory barrier?
body: <p>Condition variables are generally used such that the state they refer to is modified under a mutex. However, when the state is just a single set-only flag, there's no need for a mutex to prevent simultaneous execution. So one might want to do something like this:</p>
  
  <pre><code>flag = 1;
  pthread_cond_broadcast(&amp;cvar);
  </code></pre>
  
  <p>However, this is only safe if <code>pthread_cond_broadcast</code> implies a write memory barrier; otherwise, the waiting thread may see the condition variable broadcast before the flag write. That is, the waiting thread may awaken, consume the cvar signal, but see the flag still <code>0</code>.</p>
  
  <p>So, my question is: Do the <code>pthread_cond_broadcast</code> and <code>pthread_cond_signal</code> calls imply a write memory barrier? If so, where is this specified in the relevant POSIX (or other) specifications? <a href="http://pubs.opengroup.org/onlinepubs/7908799/xsh/pthread_cond_signal.html" rel="nofollow">The spec</a> seemed unclear on this point.</p>
  
  <p>Note: I am aware that, in practice, this does result in a memory barrier (on Linux, because thread awakening implies a full CPU memory barrier, and the cross-library function call implies a compiler memory barrier). However, I'm interested here in what the spec guarentees.</p>