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