[Top][All Lists]

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

Re: [avr-libc-dev] Should cli() imply a memory barrier?

From: Joerg Wunsch
Subject: Re: [avr-libc-dev] Should cli() imply a memory barrier?
Date: Tue, 8 Jun 2010 21:49:49 +0200
User-agent: Mutt/1.5.20 (2009-06-14)

As Bob Paddock wrote:

> cli() should produce code of "least surprise".  Most people are
> surprised when they find their explicitly placed cli() has been
> (re)moved by code reordering.

> atomic.h should be mentioned if the documentation route is the one
> chosen.

OK, I added both these.

>  Seems like there is some overlap here?

I think atomic access should be implemented using the macros from
<util/atomic.h>.  They are really clever.

Of course, that would essentially obviate the need for cli()
completely then, and sei() would only be needed during device
initialization, in order to get interrupts going for the first time...
OK, there's another purpose of sei() (where the memory barrier is not
strictly needed): if you want to re-enable interrupts inside an ISR,
to allow for interrupt nesting.

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]