[riot-notifications] [RIOT-OS/RIOT] cpu/arm7_common: Make irq_*() compiler barriers (#11440)
notifications at github.com
Fri May 24 12:16:35 CEST 2019
> If I understood you correclty, you are afraid that LTO might inline the code of these functions and reorder the memory access arround.
Exactly. The experiment in https://github.com/RIOT-OS/RIOT/pull/11438#issuecomment-486961340 shows, that GCC does this for AVR.
> If so, do you think that this could happen even if the functions are present in ELF binaries?
> One other question arose to me related to the topic. GCC for Xtensa knows an option `-mserialize-volatile`. When this option is enabled, GCC inserts `MEMW` instructions before volatile memory references to guarantee sequential consistency. This option is disabled in GCC for ESPs by default. Do you think it makes sense to enable them?
There have been some heated discussions lately on whether `volatile` can be used for synchronization. As far as I know there is pretty much a consensus: E.g. the [Linux Kernel Developers explicitly forbid this use of `volatile`](https://www.kernel.org/doc/html/latest/process/volatile-considered-harmful.html), e.g. [Intel considers `volatile` almost useless for multi-threaded programming](https://web.archive.org/web/20181124154026/https://software.intel.com/en-us/blogs/2007/11/30/volatile-almost-useless-for-multi-threaded-programming), and the C standard guys have [added an standard atomic library](https://en.cppreference.com/w/c/atomic) since C11, as they felt previous versions of C did not provide the required means to do synchronization.
My personal point of view is to stick with that consensus and do not use `volatile` for means of synchronization. As far as I know `irq_disable()` and `irq_restore()` are either used explicitly (in low level code) or indirectly through higher level APIs such as mutex (in high level code). Therefore, `-mno-serialize-volatile` should be safe. It would have a performance cost to enable `-serialize-volatile` and would slightly increase code size.
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the notifications