[En-Nut-Discussion] NutSleep implementation optimization

[Matthias Ringwald]

    Hi Harald, Ole,

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

It looks like we cuold try to focus on different timer categories.
>
> 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.

If someone has _real_ timing constraints and is using a cooperative  
OS, I guess it has to be handled from interrupt context.
BUT.. that should be used in rare occasions and people should now  
what they do. Ole could use another timer, or we could provide
a single hook in the std timer IRQ handler.

Then I can imaging single or repetitive task, that might take a while  
to process, but don't have stringent timing constraints.
For such apps, a user-space timer callback comes in handy. (although,  
basically all such activities could be performed by
a single thread which does timer processing. but I feel its better to  
have this support in the kernel and well tested).

And yes, there are NutSleep and event timeouts. they can be easiliy  
handled (as they are right now) using the user-space
callbacks or could directly handled in the kernel. As I think that  
the user-space callbacks are handy, using them for
NutSleep and Event timeout makes life easier.



>> 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.
>>
>
I don't understand that. You're saying that an app is creating more  
timers that there is available heap before they are relased in the
next thread switch. ? That's bad luck?

On the other hand, yes, I wouldn't expect a context switch to happen  
when starting I timer. But if yes, it could be written in the docs.. :)
If you say reusing elapsed timers when creating new ones, your're  
talking about processing the elapese timers which might lead to a
woken thread with higher priority? if so, then just process timers  
but don't call NuthTreadSwitch/Yield.


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

> ..
> 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.
Its the other interrupts, you don't care for timer interrupt if you  
are running there.. :)
The blocking comes from IRQ per default beeing disabled during  
processing IRQs which would otherwise get more complicated
and is called nested IRQs.

>
> Btw: Why doe we alwyys block all interrupts in a critical section  
> and not only the ones that would influence our code?
If we know exactly which one, it makes sense. Harald just started  
blocking timer interrupts if changing timer queues.
But this heavily depends on what is done from IRQ context. As we're  
moving stuff out of the IRQ handler, there's
a reduced need for critical sections. (see my mail on NutSleep).


> In case of an UART we could only block the UART interrupt and still  
> be able to process network traffic...
The problem we have on BTnut is more that kernel activity (thread  
reordering, timer irq.. )
blocks all IRQ including the UART altough the UART RX is not doing  
anything evil.


Matthias