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

Juan I Carrano notifications at github.com
Thu Apr 25 13:48:48 CEST 2019

@maribu  In that case `irq_is_in` would work fine even if `__in_isr` is not volatile: if `__in_isr gets` set at ISR entry and unset at exit then from the perspective on _any_ code - in ISR or in normal mode- `__in_isr` never changes value.

A similar issue was raised a while ago with scheduler variables. 

Another issue to watch out for is slight variation in LLVM and GCC when it comes to write barriers, as pointed out in the linux source: https://github.com/torvalds/linux/blob/6f0d349d922ba44e4348a17a78ea51b7135965b1/include/linux/compiler-gcc.h#L30

Also, I just checked and, at least in ARM, the builtin __sync_synchronize() is OK (generates a `dmb` instruction), but  it _looks_  we are breaking it by redefining it: turns out the redefinition is not effective and it does not break.

So, in conclusion, my position is:

- let's have barrier (and [barrier_data()](https://github.com/torvalds/linux/blob/6f0d349d922ba44e4348a17a78ea51b7135965b1/include/linux/compiler-gcc.h#L30) if we need it)
- I'd rather go with the proven, traditional definition using a macro.
- memory_barrier() is not adding anything special on top of __sync_synchronize().
- __sync_synchronize() should be defined ONLY on those architectures that don't have the builtin (in the cpu and not in core)

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...
URL: <http://lists.riot-os.org/pipermail/notifications/attachments/20190425/ad49462e/attachment.html>

More information about the notifications mailing list