4 ms·

Related: https://www.kernel.org/doc/Documentation/volatile-considered-harmful.txt https://www.kernel.org/doc/Documentation/volatile-considered... Sounds like "

by zurn 13y ago

Related: https://www.kernel.org/doc/Documentation/volatile-considered-harmful.txt https://www.kernel.org/doc/Documentation/volatile-considered... Sounds like "volatile" variables don't really provide good semantics for most uses even without considering compiler bugs, so it's better to just use explicit load and store macros or functions.

acqq 13y ago
That is the reason the compilers mostly didn't care: the semantics of the language "volatile" is seldom what is needed "in the real world programs."
- avian 13y ago
  As the paper notes in the introduction, "volatile" is heavily used in embedded software where synchronization primitives like kernel's spinlocks aren't readily available. The "buffer_ready" in the paper is a very good example that I have seen many times in the real world. If anyone can share the "better solution" that avoids "volatile" (and works on a bare-bone ARM microcontroller for example), I would love to see it.
  - _delirium 13y ago
    The "buffer_ready" example was given as an incorrect use, though, which won't necessarily work even in a standards-conforming compiler, because the semantics of volatile don't forbid reordering the loop (which has no volatile accesses) to go after the buffer_ready write.
  - cnvogel 13y ago
    The solution to this problem is a memory barrier. The short version of such a barrier is: Define a class of transactions (e.g. memory writes). Then all transactions before the barrier must conclude before any transaction after the barrier starts. But this doesn't give you any guarantee about transactions of other types. http://en.wikipedia.org/wiki/Memory_barrier http://en.wikipedia.org/wiki/Memory_barrier https://www.kernel.org/doc/Documentation/memory-barriers.txt https://www.kernel.org/doc/Documentation/memory-barriers.txt
  - acqq 13y ago
    I haven't programmed ARM myself and there are different ARMs, but as far as I understand (inspired by post from cnvogel), on most CPU's even non-ARM ones, you need to use intrinsics like these which exist on ARM: Memory barrier instructions: http://infocenter.arm.com/help/topic/com.arm.doc.faqs/ka14041.html http://infocenter.arm.com/help/topic/com.arm.doc.faqs/ka1404... GCC example: http://stackoverflow.com/questions/6751605/data-memory-barrier-dmb-in-cmsis-libraries-for-cortex-m3s http://stackoverflow.com/questions/6751605/data-memory-barri... As far as I understand, volatile doesn't give you the needed "barrier" semantics (what is not allowed to happen before or after, on the deep hardware level) if the code with "volatile" works, it can be just an accident.
    - zAy0LfpBZLC8mAC 13y ago
      I don't know the details for ARM, but generally, microcontroller type CPUs don't do any reordering, so no need to prevent it with barriers. And if you do use volatile correctly (and the compiler is not broken), you don't need compiler barriers either. You also might not need any CPU barriers when the cache controller is configured to treat certain regions of the address space as uncacheable (which might be used for MMIO regions).
      - acqq 13y ago
        Well, with the sufficiently primitive CPU and C compiler even volatile is not needed.
        zAy0LfpBZLC8mAC 13y ago
        Sure - except that "primitive" CPUs are still widely used, while I'd think that non-optimizing C compilers are the exception.
      - mansr 13y ago
        Modern high-performance ARM cores such as the Cortex-A15 do plenty of reordering. Even when using strongly ordered memory mappings, you still need barriers to prevent reordering between normal and strongly ordered accesses. No amount of volatile will help with this.
  - JoeAltmaier 13y ago
    Been writing embedded software for decades. Volatile is certainly NOT the feature of choice. Atomic operations including memory barrier are far more commonly used. Embedded programmers are paranoid. They check such things in the debugger (examine assembly code). Not the big issue the OP seems to think.

by zurn 13y ago

acqq 13y ago

That is the reason the compilers mostly didn't care: the semantics of the language "volatile" is seldom what is needed "in the real world programs."

avian 13y ago
As the paper notes in the introduction, "volatile" is heavily used in embedded software where synchronization primitives like kernel's spinlocks aren't readily available. The "buffer_ready" in the paper is a very good example that I have seen many times in the real world. If anyone can share the "better solution" that avoids "volatile" (and works on a bare-bone ARM microcontroller for example), I would love to see it.
- _delirium 13y ago
  The "buffer_ready" example was given as an incorrect use, though, which won't necessarily work even in a standards-conforming compiler, because the semantics of volatile don't forbid reordering the loop (which has no volatile accesses) to go after the buffer_ready write.
- cnvogel 13y ago
  The solution to this problem is a memory barrier. The short version of such a barrier is: Define a class of transactions (e.g. memory writes). Then all transactions before the barrier must conclude before any transaction after the barrier starts. But this doesn't give you any guarantee about transactions of other types. http://en.wikipedia.org/wiki/Memory_barrier http://en.wikipedia.org/wiki/Memory_barrier https://www.kernel.org/doc/Documentation/memory-barriers.txt https://www.kernel.org/doc/Documentation/memory-barriers.txt
- acqq 13y ago
  I haven't programmed ARM myself and there are different ARMs, but as far as I understand (inspired by post from cnvogel), on most CPU's even non-ARM ones, you need to use intrinsics like these which exist on ARM: Memory barrier instructions: http://infocenter.arm.com/help/topic/com.arm.doc.faqs/ka14041.html http://infocenter.arm.com/help/topic/com.arm.doc.faqs/ka1404... GCC example: http://stackoverflow.com/questions/6751605/data-memory-barrier-dmb-in-cmsis-libraries-for-cortex-m3s http://stackoverflow.com/questions/6751605/data-memory-barri... As far as I understand, volatile doesn't give you the needed "barrier" semantics (what is not allowed to happen before or after, on the deep hardware level) if the code with "volatile" works, it can be just an accident.
  - zAy0LfpBZLC8mAC 13y ago
    I don't know the details for ARM, but generally, microcontroller type CPUs don't do any reordering, so no need to prevent it with barriers. And if you do use volatile correctly (and the compiler is not broken), you don't need compiler barriers either. You also might not need any CPU barriers when the cache controller is configured to treat certain regions of the address space as uncacheable (which might be used for MMIO regions).
    - acqq 13y ago
      Well, with the sufficiently primitive CPU and C compiler even volatile is not needed.
      - zAy0LfpBZLC8mAC 13y ago
        Sure - except that "primitive" CPUs are still widely used, while I'd think that non-optimizing C compilers are the exception.
    - mansr 13y ago
      Modern high-performance ARM cores such as the Cortex-A15 do plenty of reordering. Even when using strongly ordered memory mappings, you still need barriers to prevent reordering between normal and strongly ordered accesses. No amount of volatile will help with this.
- JoeAltmaier 13y ago
  Been writing embedded software for decades. Volatile is certainly NOT the feature of choice. Atomic operations including memory barrier are far more commonly used. Embedded programmers are paranoid. They check such things in the debugger (examine assembly code). Not the big issue the OP seems to think.