Re: [Xenomai-help] Scheduler: Strange priority handling with multiple tasks waiting for one semaphore

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 2105 bytes --]

M. Koehrer wrote:
> Hi everybody,
> 
> I see strange effect that I do not understand.
> What happens when multiple tasks (with different priority) are waiting for a single semaphore?
> Assume the following situation:
> Task H (High prio) and Task L (low prio) are waiting both for the same semaphore.
> A third task does the rt_sem_v() to grant access.
> Now H passes its rt_sem_p() and runs. 
> A few statements later H calls rt_sem_v() to grant access to the semaphore protected part.
> What happens now? As H is high priority there should be no reschedule, i.e. H continues to run.
> What happens now if H wants to enter again via rt_sem_p() (on the same semaphore)?
> I expect to allow H again the access as it has a higher priority than L.
> However, a small demo application for this use case shows me that this not the case.
> The heart of my demo application is the following task code fragment:
> 
> void mytask(void *cookie)
> {
>     int id = (int)cookie;
>     int cnt = 0;
> 
>     while (!end)
>     {
>         rt_sem_p(&sem, TM_INFINITE);
>         (....)
>         rt_sem_v(&sem);

Semaphores of the native skin do not know a 'mutex' mode (because there
are explicit mutexes), so you are most likely using the wrong tool here.

Semaphores have no owner. Once you release a semaphore, you pass the
access to the next highest waiter. And, in contrast to mutexes with
strict ownership, there is no way to get it back even if the new owner
hasn't been started yet.

>     }
> 
>     printf("task %i: cnt %i\n", id, cnt);
> }
> There are two tasks with different priorities that execute this code.
> I expected to have only the higher priority task to be run, however they run alternately.
> What is happening here? It looks as if the Xenomai scheduler does not handle the priority 
> correctly in this case.
> I have enclosed the C code of this application to this mail.
> 
> Thanks for any feedback on this.
> 
> Regards
> 
> Mathias
> 

In short: use mutexes for resource protection, then you will get the
desired behaviour!

Jan



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]