[En-Nut-Discussion] NutEventPost Handling

[Matthias Ringwald]

Hi Harald,

> you're right. NutThreadAddPriQueue() inserts a thread behind
> any other with same or higher priority. Thus, the woken up
> thread is inserted behind the posting thread, if both do
> have the same priority.
>
> This way, NutYield() will remove a thread from the run-queue
> and re-insert it behind threads with higher or equal priority.

I just stole time from my office colleague discussing,
if the woken thread should be preferred to other threads that
are ready with the same priority. we agreed to: no.
so NutThreadYield() will do the trick, also guaranteeing
that no thread will starve.


> ..
>> f {
>>         NutEventWait()
>>         printf()...
>>         NutEventPost()
>> }
>>
>> T1: for (;;) f;
>> T2: for (;;) f;
>>
>> With the current implementation, T2 will never get the UART..
>>
>> other comments on this ?
>
> I agree with your view. The code above could be easily fixed
> by adding NutThreadYield(), but it makes more sense to me too,
> if NetEventPost() does this internally. Looks more consistent,
> IMHO.
Fine. I'll fix it  ASAP.

> Harald
>
> P.S. Your sample will switch the context, because sooner or later
> printf() will put the thread to sleep. But I got your point.

P.P.S: ... NO! :) surly printf will block, but as T1 didn't post
(as it owns the mutex... :) T2 will start but immediately wait
for the Queue to be signaled. when T1 wakes up again and call Post
nothing happens. (do I miss something?)