[riot-notifications] [RIOT-OS/RIOT] sys: Added simple memory barrier API (#11438)
notifications at github.com
Mon Apr 29 18:43:12 CEST 2019
> Also, I'd like to reserve "barrier.h" for IPC barriers, for which we'll eventually have an implementation.
> If you guys think that just using `__asm__ volatile ("" : : : "memory");` in the rare cases it is needed is not enough, I propose adding a proper macro to core/include/kernel_defines.h.
I'd say the main benefit is being portable, as `__asm__ volatile ("" : : : "memory");` is more of a compiler specific hack. Using a macro instead allows to add support for other compilers later on.
I'm also not sure if `core` is the right place to put it. I'd expect compiler/memory barriers to only be used directly in platform dependent code. The platform independent code should just use mutex, `irq_disable()`, or C11 atomics instead of dealing directly with barriers in my opinion.
> Providing a memory barrier API is probably not gonna help, or even hurt, as people will use it at random places without deeper understanding.
People using APIs incorrectly or in incorrect situations is a general software development issue not specific to this problem. Providing easy to use APIs and proper documentation is clearly the better way instead of not providing APIs that could potentially be misused.
Also so far all implementations of `irq_disable()`/`irq_restore()` I checked are either using externally supplied APIs (e.g. `cli()` / `sei()` on AVR, e.g. `__disable_irq()` on Cortex-M), or contained bugs regarding the use barriers. I'd say that this is anecdotal evidence that such APIs can help to prevent hard-to-trace data corruption bugs.
> I'd rather not have the examples and explanations that this PR adds. It feels opinionated and alarmist and not considering context (sorry @maribu).
I can split it off into another PR, so that the discussion about this does not stall the barrier API. But an barrier API without the knowledge when and how to use it is of little benefit. Examples and explanations are usually considered to be a good way to spread knowledge... Any help improving those is greatly appreciated.
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