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: FreeRTOS info on 26 Oct 2009 15:19 D Yuniskis wrote: >> - 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? As per "or that the hardware supports atomic semaphore type operations?", which not all architectures do. -- Regards, Richard. + http://www.FreeRTOS.org Designed for Microcontrollers. More than 7000 downloads per month.
From: D Yuniskis on 26 Oct 2009 15:29 FreeRTOS info wrote: > D Yuniskis wrote: > > >> - 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? > > As per "or that the hardware supports atomic semaphore type > operations?", which not all architectures do. Not all do. But you would be *surprised* at how many that you *think* "don't" actually *do*! All you need to do is look through the instruction set and see where each instruction can be interrupted.
From: Tim Wescott on 26 Oct 2009 15:50 On Mon, 26 Oct 2009 12:07:29 -0700, D Yuniskis wrote: > Tim Wescott wrote: >> 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. > > I look at it as the RTOS not having been designed "lean enough" (to keep > with the meat analogy :> ) > >> One man's meat... OK, I'll break every damn RTOS in the world!!! I'll just set my timer period equal to one processor tick. Hah hah hah hee hee hee heh heh heh! Now tell me that the design problem is with the RTOS's, and not with me. -- www.wescottdesign.com
From: David Brown on 26 Oct 2009 15:59 Vladimir Vassilevsky 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. > Some processors may have instructions allowing atomic accesses and locks to be created without interrupt disabling. It is also possible to have specialised hardware that can be used as the basis of a locking mechanism without needed to disable interrupts. But that is all very hardware-specific. There are also software-only methods of implementing various sorts of locks and atomic accesses, but these all have their own disadvantages, such as unbounded runtimes. For example, if you have a multi-access structure that must be accessed atomically, you can have two copies. Whenever you write to it, you update both values. When you want to read, you read both copies. If the copies are not the same, you re-do the reads until they are the same. It's simple, and avoids disabling interrupts - but it is inefficient and has unbounded run time.
From: David Brown on 26 Oct 2009 16:35
D Yuniskis wrote: > FreeRTOS info wrote: >> D Yuniskis wrote: >> >> >> - 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? >> >> As per "or that the hardware supports atomic semaphore type >> operations?", which not all architectures do. > > Not all do. But you would be *surprised* at how many > that you *think* "don't" actually *do*! All you need to do > is look through the instruction set and see where each > instruction can be interrupted. 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 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. |