[En-Nut-Discussion] NutSleep implementation optimization

[Ole Reinhardt]

Hi Harald,

I'll call you later on to discuss the new timer API, but for now, let's 
discuss this issue:

> 1. Not supporting callbacks within interrupt context breaks
> some existing apps. At least Ole Reinhardt and Ralph Mason
> stated this. On the other hand, most people voted for removal
> of this support. However, if it's removed, do we need callbacks
> at all? The kernel doesn't really, as it uses timers in two
> ways only: Thread sleep and Event timeout.

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.

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

> If we completely remove system timer callbacks, we need an
> alternative - the new application timer API demanded by Ole.
> If this new API supports timer callbacks in interrupt context,
> these callbacks may again block the whole system.

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.

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.

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.

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

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?

Bye,

Ole

-- 
kernel concepts    Tel: +49-271-771091-14
Dreisbachstr. 24   Fax: +49-271-771091-19
D-57250 Netphen    E+ : +49-177-7420433
--