[En-Nut-Discussion] NutSleep implementation optimization

[Harald Kipp]

Hi Ole,

At 08:26 14.06.2005 +0200, you wrote:

>I don't need them from within interrupt context. What I need is a 
>guaranteed latency from about 1ms from timer-event to timer callback. 
>Since we use cooperative multitasking timer callbacks from within 
>interrupt context seems to be the only solution for me.

Exactly.



>>2. Late timer release as it is implemented now in CVS HEAD may
>>cause memory overflow with some applications. A solution might be
>>to remove elapsed timers when creating new ones. _BUT_, in this
>>case thread switching has to be avoided. Threads do not expect
>>a context switch when starting a timer.
>
>In which case a memory overflow will be caused in real world? This can 
>only happen if we use realy a lot of timers, right? But you'r right, this 
>should be avoided if possible.

Agreed. The current implementation may not cause any problem
with 99.99% of applications. But it is ugly.



>I would realy suggest to remove the timer callback in the old fashion way 
>(from within interrupt context) completely, but don't remove timer 
>callbacks that will be processed outside interrupt context at all.

Why? What's the advantage if it's removed?




>Let's create a new API with the same capabilities. Perhaps let's even 
>create an api that supports max. 1 callback per timer. We could provide an 
>extra function to process a callback list.

Again, where's the advantage?




>In this case most applications would never have the need to register a 
>callback running from within the interrupt context. And the small part of 
>applications that need such a feature (e.g. my own) needs to be avare of 
>the possibility to block the whole system.

Most applications didn't use timer callbacks with the old implementation
either. What I did was to remove _kernel_ timer callbacks from interrupt
context. But we can still add support for application callback within
interrupt context.




>One other Idea is not to block all interrupts, but the timer interrupt. 
>This would not completely block the whole system.

If running in interrupt context, all interrupts are blocked unless
we allow nested interrupts. This is supported, but do you really
want to make this mandantory? If yes, we will never be able to
calculate stack usage.



>Btw: Why doe we alwyys block all interrupts in a critical section and not 
>only the ones that would influence our code? In case of an UART we could 
>only block the UART interrupt and still be able to process network traffic...
>
>Have I missed something?

Either you or me. :-) You are right for drivers. Some of them
already make use of this. And I used this in the new timer code
as well. But the kernel is unable to tell who will call
NutEventPostFromIrq(). Thus, it has to block _all_ interrupts in
NutEventWait().

Harald