[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Joerg Wunsch
Subject: [avr-libc-dev] Re: bug #22163 (atomic not working as expected in C++)
Date: Wed, 9 Jun 2010 20:36:01 +0200
User-agent: Mutt/1.5.20 (2009-06-14)

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. ;-)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]