3 ms·
> 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, int
by 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 agoIf 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 agoYeah, 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 agoMemory-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.