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

Harald Kipp harald.kipp at egnite.de
Fri Jul 17 17:37:23 CEST 2009


Updating my previous post:

Harald Kipp wrote:
> Nathan Moore wrote: 
>> *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....
...
> My favorite idea is to register tasks upfront:
> 
>  HANDLE task_x = NutRegisterTask(function, prio, delay);

After playing around with a few alternatives, I think the best solution
would be to pre-allocate a small array of task entries as a circular
buffer. All entries can be regularly transfered to a linked list by the
kernel thread.

The advantage of such a static construction is, that code and, more
important, critical sections can be reduced to a minimum.


>>> 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.
> 
> You are right. I overlooked the obvious, NutIdle is not a good candidate.

This is still one of the key problems:

- If we allow blocking, all remaining tasks are delayed.
- If we don't allow blocking, task usage is quite limited.

As far as I can say, there is no general solution. Hence, we need two
types of tasks.

While implementing the first type is straight forward, the second
non-blocking type, may be done in many ways. Currently I have no idea,
how many ways there are and which is the most promising. Just to give an
example: We may leave it to the programmer to take care. Or we add a
flag to mark a specific thread non-blockable and return an error, if
this thread tries to switch the context.

Furthermore, if we disable blocking, there are several locations within
the OS to handle task execution. Again, doing this after interrupt
return looks like a good idea, but then we need to solve the stack
problem. Making use of the stack of the currently running thread is
definitely bad.

On the other hand, implementing the blocking tasks without knowing the
design of the non-blocking variant may be a waste of time. At this point
I'm stuck.

Harald






More information about the En-Nut-Discussion mailing list