[En-Nut-Discussion] RFC: Nut/OS Tasks

[Nathan Moore]

>
>
> What do you think about the introduction of tasks? A task is a routine,
> which can be scheduled for execution. A task may be scheduled by
> ordinary code as well as interrupt routines. Task are executed by a new
> thread, running at highest priority.
>
> This follows Nathan's suggestion of an all purpose background thread.
>
> To schedule a task
>
>  int NutTaskSchedule(prio, function, param, delay);
>
> must be called. This will create a task structure, which is added to a
> priority queue.
>
>  prio Priority of the task
>  function Pointer to the function that will be executed
>  param A pointer which is passed to the function
>  delay Number of milliseconds the execution will be delayed


I had a similar idea (came from thinking about Linux's kernel threads,
functional programming
languages, and tail recursion), but I wasn't sure how well it might fit into
Nut; if the possibility
of runaway task creation might be a big problem, or if creation within an
ISR might be
an issue (memory allocation overhead and reentrancey* and possible failure).
 Also how
they should relate to current Nut threads isn't clear to me.
*If an IRQ fires while a thread is in NutHeapAlloc and the ISR wants to
create a task which
requires a memory allocation of its own....

I do like this concept though because aside from just being handy for the
already
mentioned reasons it also allows for new general purpose usage.  Essentially
any
action could be done by one time usage tasks.  Things that are currently
implemented
as threads could be done by stringing together a series of simple tasks.
 Memory
allocation would be used a lot more, but it opens up the opportunity for new
and interesting
things to be done.

>
>
> The delay parameter will make things a bit more complicated, but provide
> a convenient interface for modules that have to keep track of certain
> timeouts like TCP, DHCP, ARP etc.
>
> Not sure about the API yet. We may also need NutTaskCancel and possibly
> a few other functions.
>
> We may later think about a second task queue for low priority tasks,
> executed from NutIdle.


As long as they can't sleep.  Under the current thread model the thread
queue must
not ever truly become empty.

>
>
> We may also add a very high priority task queue, which is executed
> immediately after returning from interrupt. This would follow the
> suggestions of Duane Ellis, splitting interrupt routines into two parts
> (similar to Unix/Linux kernels). However, as Duane explained, these
> tasks must not call blocking functions.


This could just get "scheduled" by playing around with the interrupt return,
which
would be fast, but would also require asm() for every processor/compiler
combo.
It would also borrow stack space and current thread context from whatever
thread
was running when the IRQ fired.

>
>
> A last option is to allow reentrant interrupts. However, this is most
> complicated stuff


Thinking about things like reentrant ISRs gives me bad dreams.

Nathan