Ways to break your systems code using volatile (2010)
Edit: Looks like the slides had an inaccuracy (see replies).  Huh, looks like I learned something today :)<p>I think a good way of summarizing volatile is this slide from my parallel architectures class [1]:<p><pre><code>    &gt; Class exercise: describe everything that might occur during the 
    &gt; execution of this statement
    &gt;     volatile int x = 10
    &gt;
    &gt; 1. Write to memory
    &gt; 
    &gt; Now describe everything that might occur during the execution of
    &gt; this statement
    &gt;     int x = 10
    &gt; 
    &gt; 1.  Virtual address to physical address conversion (TLB lookup)
    &gt; 2.  TLB miss
    &gt; 3.  TLB update (might involve OS)
    &gt; 4.  OS may need to swap in page to get the appropriate page 
    &gt;     table (load from disk to physical address)
    &gt; 5.  Cache lookup (tag check)
    &gt; 6.  Determine line not in cache (need to generate BusRdX)
    &gt; 7.  Arbitrate for bus
    &gt; 8.  Win bus, place address, command on bus
    &gt; 9.  All caches perform snoop (e.g., invalidate their local 
    &gt;     copies of the relevant line)
    &gt; 10. Another cache or memory decides it must respond (let’s 
    &gt;     assume it’s memory)
    &gt; 11. Memory request sent to memory controller
    &gt; 12. Memory controller is itself a scheduler
    &gt; 13. Memory controller checks active row in DRAM row buffer.
    &gt;     (May &gt; need to activate new DRAM row. Let’s assume it does.)
    &gt; 14. DRAM reads values into row buffer
    &gt; 15. Memory arbitrates for data bus
    &gt; 16. Memory wins bus
    &gt; 17. Memory puts data on bus
    &gt; 18. Requesting cache grabs data, updates cache line and tags, 
    &gt;     moves line into exclusive state
    &gt; 19. Processor is notified data exists
    &gt; 20. Instruction proceeds
    &gt; * This list is certainly not complete, it’s just 
    &gt;   what I came up with off the top of my head. 
</code></pre>
It&#x27;s also worth mentioning that this assumes a uniprocessor model, so out-of-order execution is still possible which leads to complications in any sort of multithreaded or networked system (See #5, 6, 7, 8 in the OP article).<p>I think a lot of the confusion stems from the illusion that a uniprocessor + in-order execution model implies to programmers who have never dealt with system-level code.  I think in the future, performant software will require a bit more understanding of the underlying hardware on the part of your average software developer -- especially when you care about any sort of parallelism.  It doesn&#x27;t help that almost all common CS curriculum ignores parallelism until the 3rd year or more.<p>[1] <a href="http:&#x2F;&#x2F;www.cs.cmu.edu&#x2F;~418&#x2F;lectures&#x2F;12_snoopimpl.pdf" rel="nofollow">http:&#x2F;&#x2F;www.cs.cmu.edu&#x2F;~418&#x2F;lectures&#x2F;12_snoopimpl.pdf</a> - the last 2 slides