3 ms·

> Really? I was under the impression that "volatile" basically did nothing other than prevent the compiler from optimizing out a variable that appears to not ev

by exDM69 10y ago

> Really? I was under the impression that "volatile" basically did nothing other than prevent the compiler from optimizing out a variable that appears to not ever be written to, but is actually written to via an ISR or something. I think it also stops loads and stores to be reordered with other volatile loads and stores, and yes, it indeed is typically useful for memory mapped i/o, interrupt handlers and such. But most of the time it's not the right thing to do. > Also, how does the compiler usually handle global variables? Since they can be modified by some code that was linked in, does it assume them to be volatile? No, they're not considered volatile but may have stricter guarantees with reordering than local variables (esp. when combined with calls to foreign functions). If multithreaded code needs to be correct and portable, using locks or atomics is the way to go.

vardump 10y ago
> I think it also stops loads and stores to be reordered with other volatile loads and stores, and yes, it indeed is typically useful for memory mapped i/o, interrupt handlers and such. But most of the time it's not the right thing to do. It only prevents reordering by the compiler. CPU can still reorder them as much as it pleases, volatile doesn't affect it at all. Of course you're pretty safe on x86. Not so on other platforms. Typically you find this kind of issues when porting x86 code to some other platform. X86 writes are always in order with other writes. Loads are always in order to other loads. Just need to remember loads are sometimes ordered before stores. Again, volatile does not prevent CPU from reordering stores and loads.
- Dylan16807 10y ago
  If the compiler isn't preventing CPU reordering, then it has been impossible pre-2011 to use volatile for its original purpose, communicating with memory-mapped device registers. That sounds like a broken compiler to me.
  - vardump 10y ago
    Yeah, it'd not be very nice when DMA start bit in some DMA control register is poked before DMA address is still unset! Those architectures that do this typically provide specialized always serialized instructions for communicating with memory mapped devices. If not, you need to have proper fences to ensure right order. X86 stores are always in order (except for some specific instructions, but they're no concern in this context), so it doesn't need this.
  - makomk 10y ago
    Memory-mapped device registers are generally mapped in such a way that accesses bypass cache and go straight to memory. This has a fairly large performance penalty, of course.

by exDM69 10y ago

vardump 10y ago

> I think it also stops loads and stores to be reordered with other volatile loads and stores, and yes, it indeed is typically useful for memory mapped i/o, interrupt handlers and such. But most of the time it's not the right thing to do. It only prevents reordering by the compiler. CPU can still reorder them as much as it pleases, volatile doesn't affect it at all. Of course you're pretty safe on x86. Not so on other platforms. Typically you find this kind of issues when porting x86 code to some other platform. X86 writes are always in order with other writes. Loads are always in order to other loads. Just need to remember loads are sometimes ordered before stores. Again, volatile does not prevent CPU from reordering stores and loads.

Dylan16807 10y ago
If the compiler isn't preventing CPU reordering, then it has been impossible pre-2011 to use volatile for its original purpose, communicating with memory-mapped device registers. That sounds like a broken compiler to me.
- vardump 10y ago
  Yeah, it'd not be very nice when DMA start bit in some DMA control register is poked before DMA address is still unset! Those architectures that do this typically provide specialized always serialized instructions for communicating with memory mapped devices. If not, you need to have proper fences to ensure right order. X86 stores are always in order (except for some specific instructions, but they're no concern in this context), so it doesn't need this.
- makomk 10y ago
  Memory-mapped device registers are generally mapped in such a way that accesses bypass cache and go straight to memory. This has a fairly large performance penalty, of course.