[riot-notifications] [RIOT-OS/RIOT] sys: Added simple memory barrier API (#11438)

Kaspar Schleiser notifications at github.com
Fri Apr 26 12:01:36 CEST 2019


> Thus, using `volatile` as memory barrier is not possible.

I think we need to put this in context.

Using volatile as a compiler barrier e.g., in AVR periph code, is perfectly possible.
It is probably not in high-level code that might break on native, ESP32 or other more sophisticated architectures.

IMO we should come up with clear and simple guidelines for how to do accesses to variables that are shared between threads and/or ISRs. 

Providing a memory barrier API is probably not gonna help, or even hurt, as people will use it at random places without deeper understanding.

What we need are instructions like "if a variable is shared between ISR and thread(s), guard it's reads with irq_disable/restore() or use atomics". And of course we need to make sure that those functions are rock-solid, as you've already started.

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. Same for ```__sync_synchronize()```.

I'd rather not have the examples and explanations that this PR adds. It feels opinionated and alarmist and not considering context (sorry @maribu).

Also, I'd like to reserve "barrier.h" for IPC [barriers](https://en.wikipedia.org/wiki/Barrier_(computer_science)), for which we'll eventually have an implementation.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/RIOT-OS/RIOT/pull/11438#issuecomment-487002924
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/notifications/attachments/20190426/1f93b74a/attachment.html>


More information about the notifications mailing list