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: Jon Kirwan on 26 Oct 2009 16:39 On Mon, 26 Oct 2009 10:11:45 -0700 (PDT), KIRAN <kiraank(a)gmail.com> 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. I take it this is someone else's O/S, but that you have access to the code. >For example, Semaphore API's, Message Queue APIs, Runtime memory >management API's. Sounds just a bit like someone with a chainsaw seeing everything looking like a tree. It's always pretty sure to disable the general interrupts, if you want to protect data structures. But proper data design can mitigate the need. >Is enabling / disabling interrupts only to protect the kernel data? Perhaps. Might be because the design doesn't, as a matter of the design itself, protect the data. It takes some care thinking to _know_ that a design is intrinsically safe. Without that care, one may very well wind up just disabling interrupts all the time as the one and only tool at hand. >Why I am asking this is whenever interrupts are >disabled, I am scared of losing timer interrupts. Any input is >appreciated? That's a different question than all the rest. It will depend some on how the hardware handles interrupts from timers, worst case execution time between disable/enable pairs in the O/S, how often the timer interrupt _you_ are concerned about ticks, and so on. Hopefully, they've tested all this and documented it for you so that you can compare this with the timer period and hardware facilities. It could be a legitimate concern. Or not. Jon
From: Paul Keinanen on 26 Oct 2009 17:06 On Mon, 26 Oct 2009 13:30:42 -0500, Vladimir Vassilevsky <nospam(a)nowhere.com> wrote: > > >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. At least with the PDP-11 with memory to memory read/modify/write cycles (INC/DEC), I don't think that I ever disabled interrupts in order to protect data. Of course, you had to be careful with the data architecture design. The x86 architecture contains some prefixes with similar effect. Paul
From: Paul Keinanen on 26 Oct 2009 22:57 On Mon, 26 Oct 2009 13:30:42 -0500, Vladimir Vassilevsky <nospam(a)nowhere.com> wrote: > > >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. Doubly linked list or tree insertion/deletation would be quite nasty, if you can not disable task switching (or in the extreme case disable interrupts). With simpler data structures, such as FIFOs, the need to disable task switching or even disabling interrupts is greatly reduced. Disabling task switching should be avoided, since it can cause priority inheritance problems etc. Paul
From: 42Bastian Schick on 27 Oct 2009 13:07 On Mon, 26 Oct 2009 12:19:02 -0700, D Yuniskis <not.going.to.be(a)seen.com> wrote: >FreeRTOS info wrote: >> D Yuniskis wrote: >>> and then "schedule" a defered activation. So, the jiffy >>> terminates as expected. The interrupted routine (probably >>> an OS action) finishes up what it was working on, then, >>> examines a flag to see if it can "simply return" or if it has >>> to process some deferred "activity" >> >> ....and how are you protecting access to the flag - or are you assuming >> the hardware supports atomic read-modify-writes on variables - or that >> the hardware supports atomic semaphore type operations? > >Assuming you don't have a second processor... > >ever hear of a "Test and Set" instruction? "Test and set" or how you name it is impractical in a interrupt context. You just can't loop and wait for the semaphore. So you either setup some kind of post-poning of interrupts or you just lock out interrupts and let the interrupt controller do its job. The clou is where and how long to lock'em out :-) -- 42Bastian Do not email to bastian42(a)yahoo.com, it's a spam-only account :-) Use <same-name>@monlynx.de instead !
From: 42Bastian Schick on 27 Oct 2009 13:13
On Mon, 26 Oct 2009 21:35:11 +0100, David Brown <david.brown(a)hesbynett.removethisbit.no> wrote: >I suspect that Richard has looked very carefully through a very large >number of instruction sets looking for exactly that sort of instruction... > >There are certainly plenty of architectures that don't have test-and-set >instructions, or anything similar. As a general rule, test-and-set type >instructions don't fit well with the ethos of RISC, so RISC processors Hmm, I wonder which. >typically don't have such instructions. They either rely on disabling >interrupts (common for microcontrollers and smaller processors, where >this is a simple task), or have more sophisticated mechanisms such as >"reservations" used by the PPC processors. Yeah, but don't rely on it. I had to re-write great parts of my RTOS because Freescale limited the use of the reservation e.g. in MPC55xx that it is not usable anymore. -- 42Bastian Do not email to bastian42(a)yahoo.com, it's a spam-only account :-) Use <same-name>@monlynx.de instead ! |