Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Atomic extensions: 64-bit, bool, exchange #9600
Three extensions to the atomic functions in mbed_critical.h:
Bool exchange could have been used by #9520 - slightly tidying and shrinking the code.
Exchange and 64-bit operations are anticipated to be needed as part of ARMv6-M retargetting for ARMC6 atomics, as per its library documentation.
Pull request type
(Also covering #9247)
Previously code had to just do plain C loads and stores of "atomic" variables, as no atomic operations were provided by the library. Such direct accesses are indeed atomic in ARM hardware and compilers (up to 32-bit when properly aligned), but did not provide any ordering semantics. Having real atomic accesses provides a full and safe replacement for
Old style example (very synthetic):
A workaround for the ordering problems above is to also mark
New style example:
Note that you don't need to mark atomic data or atomic-protected data as
Note that "exchange" naming is inconsistent with "cas" compare-and-swap, but I would rather stay close to C11/C++11. Maybe at some point "cas" gets renamed to match C++11.
Even when we move to C++11, we may not necessarily be able to totally abandon these functions in favour of built-in compiler atomics. Some compiler versions might use spinlocks that are not safe versus interrupts or hard RTOS thread priorities, and might insert unneeded SMP barriers. It seems compilers+libraries tend to assume "application code with non-hard thread priorities".
Low value for amount of code written ratio?
There are very few atomic users, and many of them seem to be problematic (some tidy+fix patches pending from me soon). This PR is partly as the result of that tree search - seeing the people whose code was ugly due to lack of bool, signed or exchange.
But if my concerns above do hold that the off-the-shelf C library atomics might not be suitable for protecting privileged code against interrupts, then maybe it is worth fleshing this out further, including templates.
On the whole though - I'm usually happier seeing people using mutexes. Code is more likely to be correct. I almost want don't want to encourage people to use this :/ Templates might make it too easy.
@kjbracey-arm Please add release notes section, following https://os.mbed.com/docs/mbed-os/v5.11/contributing/workflow.html#functionality-change