Re: [avr-libc-dev] C11 Atomics and GCC libatomic

[Jacob Moroni]

To Markus:



I agree that a function call is a fair amount of overhead, especially in
the case of single byte operations.



The intent wasn’t to eliminate or discourage the use of the existing atomic
macros, but rather to provide support for compiling code which uses the
portable C11 atomics (or the somewhat portable GCC __atomic_X functions
directly). Routines which require absolute speed and efficiency would still
be best suited using the existing macros, but I think providing support for
the standard/GCC atomics could be useful. There are some routines such as
“__atomic_compare_exchange” [1] which are pretty convenient since you can
use the result as an expression. To accomplish the same task using the
existing macros would require you to end up implementing a function anyway
in many cases. Another (slight) advantage of using a function call is that
it prevents operations on register-stored variables from “leaking” into the
atomic block and causing interrupts to be disabled for a longer time than
expected [2].



Also, on a somewhat related note, I think there may be a bug in the
<avr/atomic.h> header, specifically, in the “__iRestore” function which is
called to restore the interrupt state after the atomic block is finished.
There’s currently a memory barrier after SREG is restored, but I think the
barrier should be before in order to ensure that any pending stores are
completed _before_ restoring the interrupt state. If the barrier is after,
I’m not sure if there’s anything preventing operations on non-volatile
variables from being reordered with respect to the restoring of SREG.



It’s likely that this problem has never been encountered in the field
because the common practice is to declare all shared globals as “volatile”,
which therefore prevents accesses to them from being reordered with respect
to access of SREG, but it seems like a possible issue to me.



If you agree, I can submit a bug report or even make the fix myself once I
figure out the process of sending in a patch. This is actually my first
time participating in any type of collaborative open source project!



[1] https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html



[2]
http://www.atmel.com/webdoc/AVRLibcReferenceManual/optimization_1optim_code_reorder.html





To Martin:



In this case, I was talking specifically about the C11 atomics that are
defined in <stdatomic.h> rather than the C++11 atomics which I believe are
defined in <atomic>. There is also another header in C++ called
<cstdatomic> which is apparently the C++ version of the C11 atomic header.
That being said, the proposed library implements the backend support
required for all of these headers, so they could likely all be implemented
(or grabbed from any other license compliant source) if need be, and I
would be glad to do it if you think it would be useful.



I still have some more testing to do involving the library, but I will post
it on my Github within the next day or so. If the higher powers agree to
accept this contribution, they can either grab it from my Github or I can
send it in. I will just need some guidance as to how to officially submit a
patch/contribution. While I’m not new at programming, I am new to the whole
“contributing to open source software” thing!



- Jake

On Fri, Jun 24, 2016 at 3:43 PM, Martin McKee <address@hidden>
wrote:

> 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 <address@hidden> 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
> > address@hidden
> > https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
> >
> _______________________________________________
> AVR-libc-dev mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
>