Disabling interrupts to protect data

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

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.

> Some OSes claim that they never disable interrupts, however from what I
> have seen it was all very impractical.

I have seen this claim too - but when you look closely you find it is
achieved by having the kernel itself execute with the absolute highest
interrupt priority - so the effect on lower priority interrupts is
exactly as if interrupts had been disabled. So while the claim is not
incorrect, it is somewhat deliberately misleading. People who are that
good at marketing should not be engineers.

[disclaimer - I don't know this to be the case for all systems that make
this claim, just the ones I know about]

--

Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.
More than 7000 downloads per month.

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.

You only need to disable interrupts if an interrupt context
can access those "shared objects" *without* observing whatever
other "mutex" mechanism you are using.

It *can* be done. But, it is a lot trickier than just
a tiny little critical region.

E.g., if the jiffy comes along (perhaps the most notable
active element that *would* be interrupt spawned and asynchronously
compete for access to those strctures), it has to notice that a
critical region has been entered (by whatever it has interrupted!)
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" (i.e. those things that the
jiffy *would* have done had it been fortunate enough to come
along "outside" that critical region.

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

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?

--

Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.
More than 7000 downloads per month.

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.

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?

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.

On Mon, 26 Oct 2009 10:11:45 -0700 (PDT), 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.

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