[riot-notifications] [RIOT-OS/RIOT] sys/atomic_utils: Functions for atomic access (#14331)

Marian Buschsieweke notifications at github.com
Tue Nov 10 14:35:05 CET 2020

> After all, some say (citation needed, I've read an article but can't find it any more) that if you do SEC_CST you're almost always asking more of the platform than you need.

tl;dr: No, I currently don't intent to extent this API to offer other guarantees than sequentially consistence. IMO that would gain only limited benefit in our context, but we would pay for that with increased complexity and confused developers.


The comparison is only for sequentially consistent. IMO, adding more variants lead to more complexity and confusion. I already had quite a few highly emotional, exhausting, and lengthy discussions on whether just adding `volatile` is enough for inter-context-communication (thread-to-thread or thread-to-isr) via shared memory. I think getting the "safest" atomic access variant as fast as possible is time better spent on than on reasoning on whether relaxing the guarantees is possible, documenting it, and discussing it.

Note that overhead for sequentially consistent atomic accesses in the context of embedded systems is often *significantly* less than it is in multi-core superscalar out-of-order CPUs. First, disabling IRQs briefly is ***much*** cheaper than a context switch to the OS and back for operations that lack lock-free implementations. And e.g. a lock on the memory bus that might cause other CPU cores to block during loads and stores from/to RAM is something we also don't need to worry about. (When we add support for multi-core MCUs, I think a high level primitive like an yet to implement `mutli_core_mutex_t` and carefully trying to avoid inter-core communication wherever possible is the better route to go.)

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/20201110/18a3190e/attachment.htm>

More information about the notifications mailing list