On Fri, 12 Jun 2015 14:40:46 -0600 Martin Sebor <msebor@xxxxxxxxxx> wrote: > The prototypical example that explains why volatile is important > is "normal" code spinning in a tight loop waiting for the ISR to > write some value to an object. It doesn't matter whether or not > the object is an element of an array. If the access to the object > isn't volatile the normal code may never see its value change. > So the volatile qualifier may not be necessary in the ISR but > is is essential outside of it. A barrier in the ISR won't help. I intend to use the ATOMIC macro only in the normal code (as in the ISR, interrupts are disabled anyway). Thanks for confirming that I don't need a barrier in the ISR. > isn't volatile the normal code may never see its value change. My use case is a bit different - I only read the array after the barrier, when the pointers into the array are updated. So, before the barrier, in the source code, there is no read from the array into registers which could then be used by the compiler to avoid another read later. But, without declaring the array volatile, how can I avoid that the compiler puts the read speculatively ahead of the barrier and, as soon as it knows the address, uses that to choose the right register - admittedly, this doesn't make sense on AVR. But how do I KNOW the compiler wont do such a thing on an architecture where a cache needs to be filled?
