Disabling interrupts to protect data
in [Embedded]
|
Prev: ALP for Real Time Clock using timer unit of HC12
Next: How to create a code in C++ for LM3S811 in IAR Embedded Workbench
From: KIRAN on 26 Oct 2009 13:11 Hi Guys, I am working on some RTOS, in which I see lot of interrupts "enabling" and "disabling" code in most of the RTOS API's to protect kernel data. For example, Semaphore API's, Message Queue APIs, Runtime memory management API's. Is enabling / disabling interrupts only to protect the kernel data? Why I am asking this is whenever interrupts are disabled, I am scared of losing timer interrupts. Any input is appreciated? Regards, Kiran
From: D Yuniskis on 26 Oct 2009 13:34 KIRAN wrote: > I am working on some RTOS, in which I see lot of interrupts "enabling" > and "disabling" code in most of the RTOS API's to protect kernel data. > For example, Semaphore API's, Message Queue APIs, Runtime memory > management API's. Is enabling / disabling interrupts only to protect > the kernel data? Why I am asking this is whenever interrupts are > disabled, I am scared of losing timer interrupts. Any input is > appreciated? A common approach to providing an atomic operation. Some CPUs don't need this. If it is done correctly, the critical region will be very small (temporally). You shouldn't *lose* a timer interrupt (nor any other) as the hardware should latch the interrupt and you will respond to it as soon as the critical region passes. (a few instructions?) If the critical region is much longer than this, the OS implementation is sloppy.
From: Tim Wescott on 26 Oct 2009 14:02 On Mon, 26 Oct 2009 10:34:33 -0700, D Yuniskis wrote: > KIRAN wrote: > >> I am working on some RTOS, in which I see lot of interrupts "enabling" >> and "disabling" code in most of the RTOS API's to protect kernel data. >> For example, Semaphore API's, Message Queue APIs, Runtime memory >> management API's. Is enabling / disabling interrupts only to protect >> the kernel data? Why I am asking this is whenever interrupts are >> disabled, I am scared of losing timer interrupts. Any input is >> appreciated? > > A common approach to providing an atomic operation. Some CPUs don't need > this. > > If it is done correctly, the critical region will be very small > (temporally). You shouldn't *lose* a timer interrupt (nor any other) as > the hardware should latch the interrupt and you will respond to it as > soon as the critical region passes. (a few instructions?) > > If the critical region is much longer than this, the OS implementation > is sloppy. .... or your timer period is too short for that RTOS/processor combination. One man's meat... -- www.wescottdesign.com
From: Tim Wescott on 26 Oct 2009 14:05 On Mon, 26 Oct 2009 10:11:45 -0700, KIRAN wrote: > Hi Guys, > > I am working on some RTOS, in which I see lot of interrupts "enabling" > and "disabling" code in most of the RTOS API's to protect kernel data. > For example, Semaphore API's, Message Queue APIs, Runtime memory > management API's. Is enabling / disabling interrupts only to protect the > kernel data? Why I am asking this is whenever interrupts are disabled, > I am scared of losing timer interrupts. Any input is appreciated? It's par for the course, and pretty much necessary on most processors. Interrupt controllers don't forget that they've been interrupted -- so if the timer pops off in the middle of a critical block the interrupt will get latched, and vectored to as soon as the OS exits the critical code. You'll only have a problem if you get _two_ timer interrupts in the space of one critical block. If this happens then you're pushing that particular RTOS/processor combination too hard, and you need to re-think some architectural decisions. -- www.wescottdesign.com
From: Vladimir Vassilevsky on 26 Oct 2009 14:30
D Yuniskis wrote: > KIRAN wrote: > >> I am working on some RTOS, in which I see lot of interrupts "enabling" >> and "disabling" code in most of the RTOS API's to protect kernel data. > A common approach to providing an atomic operation. > Some CPUs don't need this. Some OSes claim that they never disable interrupts, however from what I have seen it was all very impractical. Once you have more or less sophisticated structure of threads and interrupts, you've got to have critical parts with the interrupts disabled. Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com |