Chapter suggestion: C11 `atomic.h` and FreeRTOS

[g-berthiaume]

Hi!

First, let me thank you for this great book.

Chapter 8 of this book does a great job of introducing resource management and the problems that come with sharing.

That said, as somebody who's done a bit of multi-threaded programming on desktop, I'm a bit confused on how the kernel primitive interacts with the C11 memory model (like using atomics and memory barrier) and compiler intrinsics (like gcc's __atomic_load).

When looking at forums, I see I'm not alone with this confusion.

I believe this book could serve as an authoritative point of reference on the topic and help people bridge the gap between "desktop system programming" and "RTOS programming."

Here are some examples of questions I encountered while thinking about this topic:

When compiling with arm-none-eabi-gcc, the produced assembly will call __atomic_* functions. They are defined in the linked library libatomic. To my understanding, libatomic will implement those functions by disabling interrupts and doing some BASEPRI masking. How does this BASEPRI interact with FreeRTOS primitives?

When using _Atomic on a variable bigger than the architecture, the atomic access becomes lock-access-unlock, which is rather slower and has some implications for signal handlers.
Does that mean that I can deadlock myself using it in an ISR?

How does portMEMORY_BARRIER() interact with a function that specifies memory order like atomic_store_explicit?

Thanks for reading.

[kstribrnAmzn]

Hello @g-berthiaume! Thank you for the suggestion. I'm going to gather thoughts a couple folks on the team before proposing any way to address this.

My initial instinct is to avoid any C version-specific features in the book. FreeRTOS is built to conform with C89/C90 which is the floor of C functionality. Maintaining C version-specific explanations will become painful as more C versions are released (their aren't that many so not too bad now). This becomes orders of magnitude worse if these features are compiler specific rather than fully specified in the standard (we support many compilers).

[kstribrnAmzn]

The answer to most of your questions is that these C11 features are not kernel-aware and the kernel isn't aware of these specific features.

I'd think (need to read more on this) that the lib atomic would re-enable and unmask BASEPRI on completing. If this is the case than this is of no consequence to the kernel.

I would not expect _Atomic to cause deadlocking issues within an ISR. The access of the variable or structure/object should be atomic. Upon completion of the access the ISR would be switched to.

Note: Apologies for closing this issue. That was an accident from disconnecting my wireless mouse.

[g-berthiaume]

The answer to most of your questions is that these C11 features are not kernel-aware, and the kernel isn't aware of these specific features.

This sounds reasonable to me.

I brought up this subject because, as MCUs start to have more than one core and a weaker memory model, I think topics like C11 atomics, memory barriers and interaction with ISR become more prevalent.

I saw in this book an opportunity for a source of truth.

I would not expect _Atomic to cause deadlocking issues within an ISR. The access to the variable or structure/object should be atomic

Interesting. I'm learning about this, so I might be wrong here.
My deadlocking comments stemmed from.

If you read Beej's Guide to C Programming, you will encounter this section:

> If you use an atomic type, you can be assured that accesses to that type will be atomic… but 
> there’s a catch: if the hardware can’t do it, it’s done with a lock, instead.
> -- Beej

If the atomic implementation implements a spinlock, you could deadlock yourself if the normal thread locks a variable and then an ISR triggers.
Of course, your compiler may link a version of stdatomic that does not use lock. I'm not sure where to verify this info.

Note: Apologies for closing this issue. That was an accident from disconnecting my wireless mouse.

No problem. If you guys don't think this is in scope for this book, we can close it.