[avr-libc-dev] Re: bug #22163 (atomic not working as expected in C++)

[Joerg Wunsch]

As Dean Camera wrote:

> I concur - it makes sense to move the memory barrier to the
> definitions of the cli() and sei() macros,

(where it is now)

> There's no good reason why the user would want the compiler to
> re-order the assembly around cli() and sei(), as that's just asking
> for trouble.

There's a common miscomprehension: a memory barrier ensures that all
write operations are committed to memory, and memory locations will be
read again (so it's actually quite a big pessimization, as if all
variables were declared "volatile"), but there is currently *no*
method to prevent the compiler from reordering code.  Something like
that is simply missing in the C language.

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)