Disabling interrupts to protect data

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

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.

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.

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

On Mon, 26 Oct 2009 13:30:42 -0500, Vladimir Vassilevsky
<nospam@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
 

On Mon, 26 Oct 2009 13:30:42 -0500, Vladimir Vassilevsky
<nospam@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

On Mon, 26 Oct 2009 12:19:02 -0700, D Yuniskis
<not.going.to.be@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@yahoo.com, it's a spam-only account :-)
Use <same-name>@monlynx.de instead !

On Mon, 26 Oct 2009 21:35:11 +0100, David Brown
<david.brown@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@yahoo.com, it's a spam-only account :-)
Use <same-name>@monlynx.de instead !