[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. ;-)
- Re: [avr-libc-dev] Should cli() imply a memory barrier?, Jan Waclawek, 2010/06/08
- Re: [avr-libc-dev] Should cli() imply a memory barrier?, Joerg Wunsch, 2010/06/08
- Re: [avr-libc-dev] Should cli() imply a memory barrier?, Jan Waclawek, 2010/06/08
- Re: [avr-libc-dev] Should cli() imply a memory barrier?, Joerg Wunsch, 2010/06/08
- Re: [avr-libc-dev] Should cli() imply a memory barrier?, Jan Waclawek, 2010/06/08
- RE: [avr-libc-dev] Should cli() imply a memory barrier?, Weddington, Eric, 2010/06/08
- Re: [avr-libc-dev] Should cli() imply a memory barrier?, Joerg Wunsch, 2010/06/09