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);
}
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
--
Mathias Koehrer
[EMAIL PROTECTED]
Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren
ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT JETZT bei Arcor: günstig
und schnell mit DSL - das All-Inclusive-Paket für clevere Doppel-Sparer,
nur 39,85 inkl. DSL- und ISDN-Grundgebühr!
http://www.arcor.de/rd/emf-dsl-2
sematest.c.gz
Description: application/octetstream
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
