RFC - Nut/OS timer handling

[Ethernut]

Hi all,

Some time ago it had been suggested (by Nathan if I remember correctly)
to implement a single utility thread to handle TCP retries, ARP aging
and DHCP updates.

After evaluating this idea in more detail, the idea is to replace these
threads by Nut/OS one-shot timer callbacks.

One problem with this approach is, that timer callbacks are not running
in the same thread context that created the timer. Timer processing is
done in NutTimerProcessElapsed(), which is called in NutThreadResume()
immediately before the context switch takes place.

Btw. a weird side effect is, that runningThread may not be on top of the
runQueue when processing timer callbacks.

The main problem I see is, that more complex routines like TCP
transmission retries may use large amounts of stack space. Because
thread context is undetermined, this will add up to all running threads
and finally require more RAM than the suggested utility thread.

Before abolishing the use of timer callbacks for network timing, I'd
like to hear your opinions.

Another modification of the Nut/OS kernel, that had been suggested more
than once is thread local storage. If timer callbacks are not executed
in the same context under which the timer had been created, then the
callback routines won't be able to make use of this local storage.

A bit of Nut/OS history: Initially timer callbacks had been executed in
interrupt context. While removing all non-deterministic critical
sections, it became clear, that these callbacks can't run in interrupt
context any longer and elapsed timer processing was shifted to the
context switcher. While improving the overall responsiveness of the
kernel, this change delayed timer processing to the next context switch.
This resulted in a lot of trouble for several existing applications,
which relied on exact timings. If we want to make sure now, that timer
callbacks are called only when the related thread gains control, the
delay will increase again. I'm not sure about its impact. Furthermore,
this would require significant changes, because timers will be bound to
the thread and are no longer global. Ending the thread will destroy all
associated timers.

As usual, all comments are most welcome.

Harald

_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[Nathan Moore-5]

>
> Some time ago it had been suggested (by Nathan if I remember correctly)
> to implement a single utility thread to handle TCP retries, ARP aging
> and DHCP updates.


Close to my idea.

>
> After evaluating this idea in more detail, the idea is to replace these
> threads by Nut/OS one-shot timer callbacks.
>
> One problem with this approach is, that timer callbacks are not running
> in the same thread context that created the timer. Timer processing is
> done in NutTimerProcessElapsed(), which is called in NutThreadResume()
> immediately before the context switch takes place.
>
> Btw. a weird side effect is, that runningThread may not be on top of the
> runQueue when processing timer callbacks.
>
> The main problem I see is, that more complex routines like TCP
> transmission retries may use large amounts of stack space. Because
> thread context is undetermined, this will add up to all running threads
> and finally require more RAM than the suggested utility thread.

>
> Before abolishing the use of timer callbacks for network timing, I'd
> like to hear your opinions.


Unless something has changed recently that I haven't seen (I'm on older
version of Nut)
there is another problem.  While timers are no longer executed in interrupt
context they still
have some of the same constraints as interrupt handlers.
Particularly they should never yield.  If they do then the context switching
code becomes
reentrant.  Then bad things happen.  The run queue and the timer list would
all have to
be handled much more carefully.

I'm not sure what running a timer thread in such a way that it has access to
the context of the
thread which created the timer gets you in general cases (in special cases
it may be handled by
the application as part of the timer's *arg).  There is no guarantee that
the thread that created
the timer will still be around when the timer fires.

>
>
> Another modification of the Nut/OS kernel, that had been suggested more
> than once is thread local storage. If timer callbacks are not executed
> in the same context under which the timer had been created, then the
> callback routines won't be able to make use of this local storage.



This brings up the recently discussed locality of errno as well as thread
local pages
when paged ram is available.   While thread local storage being visible to
the timer
may be a win, it still becomes tricky since the thread might have exited by
the time
the timer fires.

I had considered creating temporary threads to handle timer like situations
when the
limitation of timer context were troublesome, but extra threads introduce
their own
problems.

Nathan
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[Ethernut]

Nathan Moore wrote:

>> Before abolishing the use of timer callbacks for network timing, I'd
>> like to hear your opinions.
>
> Unless something has changed recently that I haven't seen (I'm on older
> version of Nut)
> there is another problem.  While timers are no longer executed in interrupt
> context they still
> have some of the same constraints as interrupt handlers.
> Particularly they should never yield.  If they do then the context switching
> code becomes
> reentrant.  Then bad things happen.  The run queue and the timer list would
> all have to
> be handled much more carefully.

Good point. I overlooked the yield problem, which makes timer callbacks
unusable for interrupt driven I/O.

Harald




_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion