[En-Nut-Discussion] Report on review/rework of most Critical Sections in Nut/OS core

[Matthias Ringwald]

Hi Harald and others,

  Because of our continuing problem of loosing single bytes from the  
Bluetooth module on the BTnode, we started reducing critical sections  
everywhere and also code called by the os from interrupt context. We  
introduced NutEventPostFromIrq and removed thread queue operation  
from interrupt context. Thanks to Harald and the new timer handling  
which is mostly done during a thread switch, most parts of the os  
core don't require critical sections anymore.

To sum it up, the os only uses critical section if it would want to  
access
- the readyQueue of threads which are signaled by NutEventPostFromIrq
- any event queue which might be signaled by NutEventPostFromIrq
- the timerlist which is modified by NutTimerIrq


Based on this, I just finished going trought most os nut/os code and  
review all critical section. For BTnut, I guess there a none relevant  
ones remaining.
For others, it might be interesting to know the remaining ones which  
I guess should be reworked:

- os/msg.c: critical sections for example around processing a list  
and freeing memory [also might need work to catch up with new timer  
handling]
- net/route.c has probably unnecessary critical sections
- arch/h8300h/thread.c + arch/arm/thread.c: critical section in  
NutThreadCreate should be reduced similar to arch/arm/thread.c

then there are critical sections in the unix emulation, which are not  
as important but might be removed for others reasons
while updating the unix emulation to take benefit from  
NutEventPostFromIrq and the new timer handling.
- nut/arch/unix/thread.c: critical section required?
- nut/dev/unix_devs.c: critical section?

One remaining note: putting a NutEventWait[Next] inside a critical  
sections is not good and can be replaced by
a check on the queue in a CS and a normal NutEventWait afterwards.

Hope I didn't break something..
  Matthias