AW: [En-Nut-Discussion] Again a thread question

[Harald Kipp]

OK, the 64ms limit is something that won't fit
with many other applications too. As far as I
know, setting NUT_CPU_FREQ will reduce this
to 1ms and I think most of us would like to
have the system tick configurable.

I'd vote against a more advanced scheduling
algorithm, because this costs additional time
where it hurts most: In the context switching.

Your worker thread may do things later, where
it has to wait for something. If not, we may
add to the endless discussion about cooperative
and preemptive scheduling. In my view, there is
_finally_ not much difference between a timed
scheduler and using NutSleep().

Regarding thread killing: Right now I do not see
an easy solution without modifying the thread
API. On the other hand I don't see much difficulties
in adding something like

NutThreadMurder(NUTTHREADINFO *td)

to remove a thread from the nutThreadList and
add it to killedThread.

Harald



At 14:05 09.06.2004 +0200, you wrote:
>Hi,
>
> > higher priority thread running more often without
> > completely blocking the lower priority thread?
>
>Right. The lower priority thread does something (output on lcd) and the
>waits for one second. The Main thread shall do something with higher
>priority later... but should not block completly the display thread. On
>the other hand I would not like to wait always for at lease 64 ms (to
>not freeze the system like it is described in the documentation).
>
>Btw: Any suggestions for my killing problem?
>
>Regards,
>
>Ole
>--