Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Disabling interrupts to protect data

0 views
Skip to first unread message

KIRAN

unread,
Oct 26, 2009, 1:15:01 PM10/26/09
to
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 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?

Regards,
Kiran

Steve Watt

unread,
Oct 26, 2009, 5:48:25 PM10/26/09
to
In article <fe038650-0ee4-45e7...@m3g2000pri.googlegroups.com>,

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...

Dick Wesseling

unread,
Oct 27, 2009, 9:44:01 PM10/27/09
to
In article <hc55f9$29m1$1...@wattres.watt.com>,

Steve Watt <steve.re...@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.

0 new messages