title: Are mutex lock functions sufficient without volatile?
body: <p>A coworker and I write software for a variety of platforms running on x86, x64, Itanium, PowerPC, and other 10 year old server CPUs.</p>
  
  <p>We just had a discussion about whether mutex functions such as pthread_mutex_lock() ... pthread_mutex_unlock() are sufficient by themselves, or whether the protected variable needs to be volatile.</p>
  
  <pre><code>int foo::bar()
  {
   //...
   //code which may or may not access _protected.
   pthread_mutex_lock(m);
   int ret = _protected;
   pthread_mutex_unlock(m);
   return ret;
  }
  </code></pre>
  
  <p>My concern is caching. Could the compiler place a copy of _protected on the stack or in a register, and use that stale value in the assignment? If not, what prevents that from happening? Are variations of this pattern vulnerable?</p>
  
  <p>I presume that the compiler doesn't actually understand that pthread_mutex_lock() is a special function, so are we just protected by sequence points?</p>
  
  <p>Thanks greatly.</p>
  
  <p>Update: Alright, I can see a trend with answers explaining why volatile is bad. I respect those answers, but articles on that subject are easy to find online. What I can't find online, and the reason I'm asking this question, is how I'm protected <em>without</em> volatile. <strong>If the above code is correct, <em>how</em> is it invulnerable to caching issues?</strong></p>