Disabling interrupts to protect data

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.

One man's meat...

--
www.wescottdesign.com

It's par for the course, and pretty much necessary on most processors.

Interrupt controllers don't forget that they've been interrupted -- so if the timer pops off in the middle of a critical block the interrupt will get latched, and vectored to as soon as the OS exits the critical code.

You'll only have a problem if you get _two_ timer interrupts in the space of one critical block. If this happens then you're pushing that particular RTOS/processor combination too hard, and you need to re-think some architectural decisions.

--
www.wescottdesign.com

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.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

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.

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.

I look at it as the RTOS not having been designed "lean enough" (to keep with the meat analogy :> )

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

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.

Assuming you don't have a second processor...

ever hear of a "Test and Set" instruction?

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.

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

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.

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.

I take it this is someone else's O/S, but that you have access to the code.

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.

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.

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

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

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

"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 @monlynx.de instead !

Hmm, I wonder which.

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 @monlynx.de instead !