title: Does "volatile" guarantee anything at all in portable C code for multi-core systems?
body: <p>After looking at a <a href="https://stackoverflow.com/questions/2484980/why-is-volatile-not-considered-useful-in-multithreaded-c-or-c-programming?noredirect=1&amp;lq=1">bunch</a> <a href="https://stackoverflow.com/questions/78172/using-c-pthreads-do-shared-variables-need-to-be-volatile">of</a> <a href="https://stackoverflow.com/questions/6837699/are-mutex-lock-functions-sufficient-without-volatile?noredirect=1&amp;lq=1">other</a> <a href="https://stackoverflow.com/questions/23449562/when-would-you-need-a-volatile-pointer">questions</a> <a href="https://stackoverflow.com/questions/2478397/atomic-swap-in-gnu-c/2478520#2478520">and</a> <a href="https://stackoverflow.com/a/44243426/706054">their</a> <a href="https://stackoverflow.com/a/2485733/706054">answers</a>, I get the impression that <strong>there is no widespread agreement on what the "volatile" keyword in C means exactly.</strong></p>
  
  <p>Even the standard itself does not seem to be clear enough for everyone to agree on <a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1956.htm" rel="nofollow noreferrer">what it means</a>.</p>
  
  <p>Among other problems:</p>
  
  <ol>
  <li>It seems to provide different guarantees depending on your hardware and depending on your compiler.</li>
  <li>It affects compiler optimizations but not hardware optimizations, so on an advanced processor that does its own run-time optimizations, it is not even clear whether the compiler <em>can</em> prevent whatever optimization you want to prevent. (Some compilers do generate instructions to prevent some hardware optimizations on some systems, but this does not appear to be standardized in any way.)</li>
  </ol>
  
  <p>To summarize the problem, it appears (after reading a lot) that "volatile" guarantees something like: <em>The value will be read/written not just from/to a register, but at least to the core's L1 cache, in the same order that the reads/writes appear in the code.</em> But this seems useless, since reading/writing from/to a register is already sufficient within the same thread, while coordinating with L1 cache doesn't guarantee anything further regarding coordination with other threads.  I can't imagine when it could ever be important to sync just with L1 cache.</p>
  
  <p><strong>USE 1</strong>
  <br>
  The only widely-agreed-upon use of volatile seems to be for old or embedded systems where certain memory locations are hardware-mapped to I/O functions, like a bit in memory that controls (directly, in the hardware) a light, or a bit in memory that tells you whether a keyboard key is down or not (because it is connected by the hardware directly to the key).</p>
  
  <p>It seems that <strong>"use 1" does not occur in portable code whose targets include multi-core systems.</strong></p>
  
  <p><strong>USE 2</strong>
  <br>
  Not too different from "use 1" is memory that could be read or written at any time by an interrupt handler (which might control a light or store info from a key).  But already for this we have the problem that depending on the system, the interrupt handler <a href="https://stackoverflow.com/q/33955582/706054">might run on</a> <a href="https://stackoverflow.com/a/25153972/706054">a different core</a> with <a href="https://stackoverflow.com/a/954069/706054">its own memory cache</a>, and "volatile" does not guarantee cache coherency on all systems.</p>
  
  <p>So <strong>"use 2" seems to be beyond what "volatile" can deliver.</strong></p>
  
  <p><strong>USE 3</strong>
  <br>
  The only other undisputed use I see is to prevent mis-optimization of accesses via different variables pointing to the same memory that the compiler doesn't realize is the same memory.  But this is probably only undisputed because people aren't talking about it -- I only saw one mention of it.  And I thought the C standard already recognized that "different" pointers (like different args to a function) might point to the same item or nearby items, and already specified that the compiler must produce code that works even in such cases.  However, I couldn't quickly find this topic in the latest (500 page!) standard.</p>
  
  <p>So <strong>"use 3" maybe doesn't exist</strong> at all?</p>
  
  <p><em>Hence my question:</em></p>
  
  <p><strong>Does "volatile" guarantee anything at all in portable C code for multi-core systems?</strong></p>
  
  <hr>
  
  <h2>EDIT -- update</h2>
  
  <p>After browsing the <a href="https://web.archive.org/web/20181230041359if_/http://www.open-std.org/jtc1/sc22/wg14/www/abq/c17_updated_proposed_fdis.pdf" rel="nofollow noreferrer">latest standard</a>, it is looking like the answer is at least a <em>very</em> limited yes:
  <br>
  1.  The standard repeatedly specifies special treatment for the specific type "volatile sig_atomic_t".  However the standard also says that use of the signal function in a multi-threaded program results in undefined behavior.  So this use case seems limited to communication between a single-threaded program and its signal handler.
  <br>
  2. The standard also specifies a clear meaning for "volatile" in relation to setjmp/longjmp. (Example code where it matters is given in other <a href="https://stackoverflow.com/questions/1393443/setjmp-longjmp-and-local-variables">questions</a> and <a href="https://stackoverflow.com/questions/7996825/why-volatile-works-for-setjmp-longjmp">answers</a>.)</p>
  
  <p>So the more precise question becomes:
  <br>
  <strong>Does "volatile" guarantee anything at all in portable C code for multi-core systems, apart from (1) allowing a single-threaded program to receive information from its signal handler, or (2) allowing setjmp code to see variables modified between setjmp and longjmp?</strong></p>
  
  <p><em>This is still a yes/no question.</em></p>
  
  <p><em>If "yes", it would be great if you could show an example of bug-free portable code which becomes buggy if "volatile" is omitted.  If "no", then I suppose a compiler is free to ignore "volatile" outside of these two very specific cases, for multi-core targets.</em></p>