I don't comment often, but... There are, for C++ work, a number of advantages to supporting the standardized atomic types. And, we *are* talking here about C++ support rather than C support, which is rather more lacking in avr-lib-c. Besides making code more portable, the standard atomics library works in a well quantified manner and is, thus, safer for someone that moves between different platforms. Plus, the C++ standard atomic functionality has a much wider range of granularity than the current avr-libc atomic header. It is possible to protect blocks of code, but, moreover, atomic types allow for *type-safe* atomic access to single values with only minimal periods of interrupts being disabled. Granted, this is entirely possible with a block critical section, but the code is much more complicated than the direct value access of the "atomic type."
Finally, the C++ atomics are typically, and this is what Jacob is describing above, I believe, implemented with a combination of compiler intrensics and template metaprogramming. The result is that there is no function call. The code is inlined, just like a macro. As such, there is no additional cost I for one would welcome this as an addition to the current library. Martin Jay McKee On Fri, Jun 24, 2016 at 10:02 AM, Markus Hitter <m...@jump-ing.de> wrote: > Am 24.06.2016 um 16:21 schrieb Jacob Moroni: > >> With this library, I was also able to include a portable version of the >> <stdatomic.h> header which allows for the successful use of C11 atomic >> types! >> >> I would like to get this merged into avr-libc >> > > What's wrong with the atomic macros already existing? > > http://www.nongnu.org/avr-libc/user-manual/atomic_8h.html > > A function call is rather heavyweight for something as simple as locking > interrupts. > > As the above macros require C99, Teacup Firmware created a similar macro > set working on C89, too: > > https://github.com/Traumflug/Teacup_Firmware/blob/master/memory_barrier.h > > > Markus > > -- > - - - - - - - - - - - - - - - - - - - > Dipl. Ing. (FH) Markus Hitter > http://www.jump-ing.de/ > > > _______________________________________________ > AVR-libc-dev mailing list > AVR-libc-dev@nongnu.org > https://lists.nongnu.org/mailman/listinfo/avr-libc-dev > _______________________________________________ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
