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 way 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?
>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 way 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?
In any reasonable RTOS, the amount of time that all interrupts are disabled will be minimal. Interrupts that come in while disabled are not "lost", they are simply held pending until the interrupts are enabled.
On the other hand, if the RTOS can leave interrupts disabled for an entire clock tick, then you are at risk of losing an interrupt. You also have a buggy OS (it no longer counts as an RTOS) if it can leave interrupts disabled that long.
Note that interrupt disabling only works in a uniprocessor environment, so any OS that depends on that for implementing its primitives is going to get in trouble on modern systems. -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.5" / 37N 20' 15.3" Internet: steve @ Watt.COM Whois: SW32-ARIN Free time? There's no such thing. It just comes in varying prices...
In article <hc55f9$29m...@wattres.watt.com>, Steve Watt <steve.removet...@Watt.COM> writes:
> Note that interrupt disabling only works in a uniprocessor environment, > so any OS that depends on that for implementing its primitives is > going to get in trouble on modern systems.
Not quite. A multiprocessor kernel obviously needs to lock out other cpus, e.g. with an atomic compare and exchange, but that still leaves the problem of other processes or interrupt handlers on the current cpu interfering with the primitive.
|
