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

[Harald Kipp]

duane ellis wrote:
> Harald Kipp wrote:
>> a) Use a global variable to fix the existing NutEnterCritical / 
>> NutExitCritical and declare it obsolete.
>>
>> b) Create new macros with a parameter and replace the old one in all 
>> Nut/OS libraries.
>>   
> Harald, please see the exchange between my self and Nathan (the *LONG* 
> responses from me)
> about mixing both methods, I describe exactly using both.

Duane,

Found that one and read it more intensely. Not yet sure if I understood 
all details.

There is one point where I stumbled: Access to the list of delayed 
action functions.

The interrupt handler will add new items to it. If there is no critical 
section active, it will enable interrupts and execute the listed action 
functions and remove them from the list. In case of any active critical 
section, this will be done by EXIT_CRITICAL later on.

Wouldn't it be required to protect the manipulation of this list?

Furthermore, because action functions may be executed in interrupt 
context, they are still not allowed to call other APIs than 
NutEventPostFromIrq, right? Access to all resources they use (e.g. rx/tx 
buffers in the UART driver) must be protected.

Get me right. I like the idea of second level interrupt handling, 
because it's much more consistent and cleaner compared to what we have 
now. Just want to make sure that I understood the finer details.

Harald



P.S.(XXL):

Unfortunately the latest changes to the Nut/OS v4 interrupt handling are 
not well documented. Let me give a short summary.

Generally we have three types of interrupt handlers:

a) Handler does all the work. Example: Blinking LED on timer interrupts.

b) Handler does nothing except calling NutEventPostFromIrq. Example: 
Ethernet drivers don't need to provide real time performance because of 
large buffers.

c) Handler does the required real time work and then calls 
NutEventPostFromIrq to let userland threads do the bulk work. Example: 
UART driver, which must empty the receiver register fast, while the 
stdio stuff can be done in a cooperative fashion by the user threads.

NutEventPostFromIrq is special. Instead of moving the thread from the 
wait queue to the ready-to-run queue (like Nut/OS v3 and earlier), it 
simply increments a "pending event counter". This counter is later 
examined by NutThreadResume. The advantage is, that no linked list 
manipulation is required in interrupt context. The disadvantage is, that 
NutThreadResume must check the complete list of threads for pending 
(delayed) events.