All of lore.kernel.org
 help / color / mirror / Atom feed
From: "M. Koehrer" <mathias_koehrer@domain.hid>
To: xenomai@xenomai.org
Subject: [Xenomai-help] Scheduler: Strange priority handling with multiple tasks waiting for one semaphore
Date: Mon, 14 May 2007 10:40:19 +0200 (CEST)	[thread overview]
Message-ID: <19756477.1179132019857.JavaMail.ngmail@domain.hid> (raw)


[-- Attachment #1.1: Type: text/plain, Size: 1872 bytes --]

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
mathias_koehrer@domain.hid


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

[-- Attachment #2: sematest.c.gz --]
[-- Type: application/octetstream, Size: 664 bytes --]

             reply	other threads:[~2007-05-14  8:40 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-14  8:40 M. Koehrer [this message]
2007-05-14  9:42 ` [Xenomai-help] Scheduler: Strange priority handling with multiple tasks waiting for one semaphore Dmitry Adamushko
2007-05-14  9:45 ` Jan Kiszka
2007-05-14 10:00 ` Philippe Gerum
2007-05-14 11:57   ` [Xenomai-help] Scheduler: Strange priority handling M. Koehrer
2007-05-14 12:14     ` Dmitry Adamushko
2007-05-14 12:17     ` Philippe Gerum

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=19756477.1179132019857.JavaMail.ngmail@domain.hid \
    --to=mathias_koehrer@domain.hid \
    --cc=xenomai@xenomai.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.