[riot-notifications] [RIOT-OS/RIOT] cpu/atmega_common: RTT and RTC support (#8842)

ZetaR60 notifications at github.com
Thu Apr 18 18:44:34 CEST 2019

> So the access to `TIMSK2` will be "a fence" regarding the reordering of sequence points. There really is nothing to gain from declaring `rtt_state` to be `volatile`.

This is _incorrect_, volatile _does not_ provide any assurance that things will not be reordered _with respect to non-volatile access_. In order for `rtt_state` to be prevented from being reordered with respect to `TIMSK2` _they must both be volatile_. Please read the documentation I referred you to more carefully; the GCC one _specifically_ states this on the paragraph immediately after the one that I quoted from:

> Accesses to non-volatile objects are not ordered with respect to volatile accesses. You cannot use a volatile object as a memory barrier to order a sequence of writes to non-volatile memory.

Please do not make strong imperative claims of code change necessity when someone has _specifically cited_ exactly passages official documentation without ensuring that you understand the citation that was made.

Now, you have correctly pointed out in your inline comment that I have a few remaining issues with returning possible inconsistent results due to the timer interrupting in the middle of non-atomic operations. I will work on fixing these; however, the fix is to utilize the same approach of disabling the interrupt via a volatile register followed by access to the volatile state struct.

You may have an incorrect perception that my code is intended to provide general multi-thread access. Like the other periph systems, it does not. The use of volatile is specifically to prevent the timer events from creating an inconsistent state by disabling those events before accessing `rtt_state` / `rtc_state`. If an application requires multi-thread access to the API, it must globally disable interrupts like with every other periph system. It is only interrupt safe from events internal to the RTT/RTC system.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/notifications/attachments/20190418/35b6b4b7/attachment.html>

More information about the notifications mailing list