title: Why is volatile not considered useful in multithreaded C or C++ programming?
body: <p>As demonstrated in <a href="https://stackoverflow.com/questions/2478397/atomic-swap-in-gnu-c/2478520#2478520">this answer</a> I recently posted, I seem to be confused about the utility (or lack thereof) of <code>volatile</code> in multi-threaded programming contexts.</p>
  
  <p>My understanding is this: any time a variable may be changed outside the flow of control of a piece of code accessing it, that variable should be declared to be <code>volatile</code>.  Signal handlers, I/O registers, and variables modified by another thread all constitute such situations.</p>
  
  <p>So, if you have a global int <code>foo</code>, and <code>foo</code> is read by one thread and set atomically by another thread (probably using an appropriate machine instruction), the reading thread sees this situation in the same way it sees a variable tweaked by a signal handler or modified by an external hardware condition and thus <code>foo</code> should be declared <code>volatile</code> (or, for multithreaded situations, accessed with memory-fenced load, which is probably a better a solution).</p>
  
  <p>How and where am I wrong?</p>