[En-Nut-Discussion] Not fixed!!!: Re: confirmed!!! Re: NutOS 4.4.0 on ARM7: possibly bug in NutEnterCritical / NutExitCritical

Henrik Maier hmlists at focus-sw.com
Mon Feb 25 07:43:10 CET 2008

For my opinion it's getting too complicated with the critical section code.
Why not keep simple things simple. 

The most simplest implementation of NutEnterCritical/NutExitCritical would
do a cli or sei instruction (disable interrupts and enable interrupts). 

The only reason why we would have to involve the stack is
a) to allow nesting of critical sections
b) we don't know the interrupt state before entering the section

I think we should assume that the default state of Nut/OS is having
interrupts always enabled as it should be true for any RTOS. Then case b)
can be reduced to the fact that interrupts are always enabled when entering 
a critical section. Again if that is true we always can enable it when
leaving the critical section.
If we then can also assume that critical sections must not be nested, both
cases a) and b) are covered.

I inspected the approx. 150 places in the code of Nut/OS. Critical sections
are mostly used in device drivers covering short sections of code and there
are only few places where there are calls of subroutines. I am sure these
can be inspected for potentially nesting issues and refactored.

A critical section is what it is. The code inside is "critical" and a
programmer must know what he does when embedding code in them. He also
should be aware of the potential unsafe side effects of calling into library
functions like printf or the like.


More information about the En-Nut-Discussion mailing list