[Xenomai-help] Newbie question about priorities of xenomai Threads
Dear all, My name is Paolo and i am brand new to Xenomai :-) I downloaded and installed the stable version of Xenomai, 2.0.1. I tried a few demos, and some POSIX skin examples: they work just fine :-). Then and I started reading the documentation and some code (I have to say it is very well done). Sorry if my first questions will be a little bit simple and obvious. I have a first question related to Xenomai Threads priorities and scheduling. In particular I refer to the "Common priority scheme" in the "Life with Adeos" document. What I understood is the following: - Xenomai threads have a priority value that is compatible (let's say transparent) between the primary and secondary domain. - Xenomai threads in secondary mode and Linux real time threads (let's say those with SCHED_FIFO or SCHED_RR policy) have compatible priority values. - Among the pool of ready Xenomai threads, the Xenomai thread with highest priority is scheduled first. - If the selected xenomai thread is in secondary mode and there is a Linux thread with higher priority, the Linux thread is scheduled first. First example: - Suppose that at a rescheduling we have the following thread in the ready queues - High Priority -> Linux thread H - Medium Priority -> Xenomai thread M in PRIMARY domain - Low Priority -> Xenomai thread L in primary domain Then, the Xenomai scheduler will select M, and M will be dispatched. Second example: -- - High Priority -> Linux thread H - Medium Priority -> Xenomai thread M in SECONDARY domain - Low Priority -> Xenomai thread L in primary domain Then, the Xenomai scheduler will select M. but M is in secondary mode, which means the Linux kernel will be scheduled. The Linux scheduler knows H (it's a linux thread), M (it's in secondary mode), and maybe about L (if it has been created by UVMs). The Linux scheduler will choose H, and H will be scheduled. Is that right? bye Paolo Gai http://www.evidence.eu.com ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
[Xenomai-help] Xenomai 2.0.1 - Posix Skin - realtime priorities - what I'm doing wrong?
Dear all, First of all, I would like to thank Philippe for the long and exaustive reply to my previous post about the scheduling example. I'm now trying the POSIX skin to write a very simple example using real-time priorities, RR and FIFO scheduling. The idea is that a high priority task creates two medium priority tasks (that just prints something using printf) and a low priority task (that prints a message). The example is run twice, in one case the medium priority tasks have SCHED_FIFO, in another case they have SCHED_RR. I would expect that in both cases the two medium priority tasks would run printing their characters (either in a FIFO order or mixed when using RR), and at their end the low priority task would have run printing its message. Instead, both with and without Xenomai, I obtain an output similar to the following one. -- [EMAIL PROTECTED] xenomai-demos]# ./ex_rr #LOW priority thread!!! ...###......###...######...###........##...###...###...###.#.....#LOW priority thread!!! [EMAIL PROTECTED] xenomai-demos]# -- I attach the source code of the example... Does the behavior I obtain is normal? What I'm doing wrong? bye Paolo example.tbz2 Description: Binary data ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Xenomai 2.0.1 - Posix Skin - realtime priorities - what I'm doing wrong?
Dear Gilles,
Thanks again for the answer...
Gilles Chanteperdrix wrote:
[...]
What happens for certain is that the access to stdout buffer, when
compiling with the -D_REENTRANT flag, is serialized with a GNU libc
POSIX mutex. This account for the consistent behaviour between GNU libc
libpthread, or Xenomai POSIX skin library. The scheduling order is the
one of the libc POSIX library, and knowing exactly what happens would
require further investigation (there may be a difference between NPTL
and linuxthreads for example).
yes, I agree that mutexes called inside stdout primitives could change
the behavior of the scheduler... and that understanding what really
happens in this case is probably out of the scope of the mailing list.
Working around this issue means using calls to unlocked versions of libc
functions protected with Xenomai POSIX mutexes, such as, for example,
myputs and myputchar (sufficient for Paolo example) defined as :
[...]
Ok! I tried it, and I also tried another slightly modified version of
the demo, that simply replaces putchars with an unprotected array of
chars (let's suppose there are no race conditions) that is printed out
to stdout at the end of the game.
the results are the following, where the first part is RR and the second
is FIFO (it's quite strange for me that FIFO has more contect changes
than RR (?))
[EMAIL PROTECTED] xenomai-demos]# ./rt_ex_rr2
##L...###.###....
...###L.......#..##.#.#.#.#.###.#.####.##
and, moreover, another strange thing is that the threads does not call
any primitive...!!!
(I attach the two modified examples)
Now, your answer yields another important question: are domain
migrations inocuous from a scheduling point of view ?
Intuitively, if two tasks A and B in the same priority group are
runnable, and task A undergoes a migration from secondary to primary,
followed by a migration from primary to secondary without a suspension,
the scheduling order will be wrong.
The reason for this behaviour is that when task A migrates from
primary mode to secondary mode and will be waken up in Linux scheduler,
it should be put at the end of its priority group, so that B should
become the running task.
In short, the two successive migrations are equivalent to calling
sched_yield() from Linux scheduler point of view.
Ok, seems reasonable from the Xenomai point of view, excepts that users
should be aware of this behavior since they may make assumptions on the
non-preemptability at a given priority level of a particular piece of
code...
bye
Paolo
#include
#include
#include
/* for sched_param.c */
#include
/* */
/* unprotected buffer to avoid migrations */
char buf[1];
volatile char *buf_current=buf;
void myputchar(char c)
{
*buf_current++ = c;
}
void myprintbuf(void)
{
*buf_current=0;
puts(buf);
}
/* */
void *low(void *arg)
{
myputchar('L');
return NULL;
}
void *medium(void *arg)
{
int i,j;
for (i=0; i<300; i++) {
for (j=0; j<100; j++) ;
myputchar(((char *)arg)[0]);
}
return NULL;
}
void my_create(int policy)
{
pthread_t th1, th2, th3;
pthread_attr_t medium_attr, low_attr;
struct sched_param medium_policy, low_policy;
pthread_attr_init(&medium_attr);
pthread_attr_setschedpolicy(&medium_attr, policy);
medium_policy.sched_priority = 2;
pthread_attr_setschedparam(&medium_attr, &medium_policy);
pthread_attr_init(&low_attr);
pthread_attr_setschedpolicy(&low_attr, SCHED_FIFO);
low_policy.sched_priority = 1;
pthread_attr_setschedparam(&low_attr, &low_policy);
pthread_create(&th1, &medium_attr, medium, (char *)".");
pthread_create(&th2, &medium_attr, medium, (char *)"#");
pthread_create(&th3, &low_attr, low, NULL);
Re: [Xenomai-help] Xenomai 2.0.1 - Posix Skin - realtime priorities - what I'm doing wrong?
Gilles Chanteperdrix wrote: Paolo Gai wrote: > Gilles Chanteperdrix wrote: > >Working around this issue means using calls to unlocked versions of libc > >functions protected with Xenomai POSIX mutexes, such as, for example, > >myputs and myputchar (sufficient for Paolo example) defined as : > >[...] > > > > > Ok! I tried it, and I also tried another slightly modified version of > the demo, that simply replaces putchars with an unprotected array of > chars (let's suppose there are no race conditions) that is printed out > to stdout at the end of the game. There is no race condition in the SCHED_FIFO case or ahem, there should be none. Yes, that's true... Please also note that the "volatile" qualifier seem misplaced in your declaration of buf_current, it may matter since the compiler will probably inline calls to myputchar in the "medium" function, and buf_current will end up in a register. But this would have no effect only in the SCHED_FIFO case. Ouch! I just added it in the last tries and I forgot to remove it - sorry; However, I checked the source code produced by the compiler on i386 with the default compiler of FC3 and the code produced is the same with and without volatile; > the results are the following, where the first part is RR and the second > is FIFO (it's quite strange for me that FIFO has more contect changes > than RR (?)) Please also note that any thread created with the SCHED_RR attribute will be a plain Linux thread, and due to a bug in glibc, the thread will use the default policy. The results are strange indeed for SCHED_FIFO, it may be a bug, this needs a closer look... Maybe threads are not Xenomai threads using SCHED_FIFO policy at all ? Ok... I've done some more experiments. here are some results, with screenshots :-) First thing, I found this snippet http://sources.redhat.com/ml/glibc-bugs/2004-05/msg3.html that shows how on Linux and NPTL setting realtime priorities simply fails... I tried it on my FC3, and the behavior is the same, confirming the bug on my distro. Then, I slightly modified the example of the previous posts, setting the thread priorities with pthread_setschedparam. Case 1/Linux: Printing on the console using stdio, Linux real-time threads Screenshot: [EMAIL PROTECTED] xenomai-demos]# ./ex_rr3 thread id = 0xb7f0dbb0, policy = SCHED_OTHER, priority = 0 thread id = 0xb7f0dbb0, policy = SCHED_RR, priority = 3 ...###...###...###...###...###...######......###...###...###...###...###...######......###...###...###.#LOW priority thread!!! LOW priority thread!!! [EMAIL PROTECTED] xenomai-demos]# everything is fine, SCHED_RR and SCHED_FIFO works as expected, while the demo runs the XServer is freezed. Case 1/Xenomai: Printing on the console using stdio, Xenomai real-time threads Screenshot: [EMAIL PROTECTED] xenomai-demos]# ./rt_ex_rr3 thread id = 0xb7fc7bb0, policy = SCHED_OTHER, priority = 0 pthread_setschedparam failed: Success thread id = 0xb7fc7bb0, policy = SCHED_OTHER, priority = 0 pthread_
Re: [Xenomai-help] Xenomai 2.0.1 - Posix Skin - realtime priorities - what I'm doing wrong?
Ok, after having clicked ion the send button, I also discovered that
NPTL uses INHERIT_SCHED by default in the pthread attributes
http://sources.redhat.com/bugzilla/show_bug.cgi?id=145
I added it to the original examples, and I obtained the following
(basically it is similar to the Case 1 depicted before...)
Linux Real-Time Threads
[EMAIL PROTECTED] xenomai-demos]# ./ex_rr
LOW priority thread!!!
...###...###...###...###...###...###...###...###...###...###...###...###...###...###...###...###...###.#LOW
priority thread!!!
[EMAIL PROTECTED]
xenomai-demos]#
--> that's fine;
Xenomai Threads:
[EMAIL PROTECTED] xenomai-demos]# ./rt_ex_rr
LOW priority thread!!!
.######...######LOW
priority thread!!!
[EMAIL PROTECTED]
xenomai-demos]#
That is not what should be :-(
Again, in this case there may be an additional influence of using the
stdio with mutexes and so on...
bye
Paolo
/*
* Linux FIFO/RR scheduler demo
*
* This demo creates a few tasks scheduled with the SCHED_FIFO or the
* SCHED_RR scheduler
*
* Copyright (C) 2002 by Paolo Gai
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
#include
#include
#include
/* for sched_param.c */
#include
void *low(void *arg)
{
printf("LOW priority thread!!!\n");
return NULL;
}
void *medium(void *arg)
{
int i,j;
for (i=0; i<300; i++) {
for (j=0; j<100; j++) ;
printf((char *)arg);
}
return NULL;
}
void my_create(int policy)
{
pthread_t th1, th2, th3;
pthread_attr_t medium_attr, low_attr;
struct sched_param medium_policy, low_policy;
pthread_attr_init(&medium_attr);
pthread_attr_setinheritsched(&medium_attr, PTHREAD_EXPLICIT_SCHED);
pthread_attr_setschedpolicy(&medium_attr, policy);
medium_policy.sched_priority = 2;
pthread_attr_setschedparam(&medium_attr, &medium_policy);
pthread_attr_init(&low_attr);
pthread_attr_setinheritsched(&medium_attr, PTHREAD_EXPLICIT_SCHED);
pthread_attr_setschedpolicy(&low_attr, SCHED_FIFO);
low_policy.sched_priority = 1;
pthread_attr_setschedparam(&low_attr, &low_policy);
pthread_create(&th1, &medium_attr, medium, (char *)".");
pthread_create(&th2, &medium_attr, medium, (char *)"#");
pthread_create(&th3, &low_attr, low, NULL);
pthread_attr_destroy(&medium_attr);
pthread_attr_destroy(&low_attr);
pthread_join(th1, NULL);
pthread_join(th2, NULL);
pthread_join(th3, NULL);
}
void *high(void *arg)
{
/* first experiment:
- two medium priority thread scheduled with RR
- one low priority thread scheduled with FIFO
*/
my_create(SCHED_RR);
/* second experiment:
- two medium priority thread scheduled with FIFO
- one low priority thread scheduled with FIFO
*/
my_create(SCHED_FIFO);
return NULL;
}
int main()
{
pthread_t mythread;
pthread_attr_t myattr;
struct sched_param mypa
[Xenomai-help] Xenomai 2.0.1 - Posix Skin - implementing a periodic thread
Dear all,
here is another small demo... this time of a periodic thread in POSIX.
It works under Xenomai, but it fails under Posix Real-Time.
The reason of the failure is the SIGUSR1 not being blocked by the main
thread. If in main() the comments below the note "// REMOVE THE COMMENTS
BELOW" are removed, then the signal is masked also in the main(), and as
a result the POSIX version works.
The question I have is if the behavior in Xenomai (that is, not failing
like the POSIX counterpart) is correct or not...
bye
Paolo
--
Evidence S.R.L. - Paolo Gai, CEO
http://www.evidence.eu.com Tel: +39 0587 274823 Fax: +39 0587 291904
#include
#include
#include
#include
#include
#include
#include
void abort_perror(const char *msg)
{
perror(msg);
exit(1);
}
void *my_periodic_thread (void *cookie)
{
struct itimerspec its;
struct sigevent sig;
sigset_t blocked;
siginfo_t si;
timer_t mytimer;
int i;
/* create a timer that will be used to periodically send a signal */
sig.sigev_notify = SIGEV_SIGNAL;
sig.sigev_signo = SIGUSR1;
sig.sigev_value.sival_ptr = &sig;
if(timer_create(CLOCK_REALTIME, &sig, &mytimer))
abort_perror("timer_create");
/* block the signal used by the timer */
sigemptyset(&blocked);
sigaddset(&blocked, SIGUSR1);
pthread_sigmask(SIG_BLOCK, &blocked, NULL);
/* set the periodic timer */
its.it_value.tv_sec = 0;
its.it_value.tv_nsec = 4000; /* 40 ms */
its.it_interval.tv_sec = 0;
its.it_interval.tv_nsec = 2000; /* 20 ms */;
if(timer_settime(mytimer, 0, &its, NULL))
abort_perror("timer_settime");
printf("periodic thread started...\n");
for (i=0; i<40; i++) {
while (sigwaitinfo(&blocked, &si) == -1 && errno == EINTR);
/* The thread body */
printf("%d\n",i);
}
printf("...periodic thread end!\n");
timer_delete(mytimer);
return NULL;
}
int main()
{
pthread_t mythread;
pthread_attr_t myattr;
struct sched_param myparam;
void *returnvalue;
sigset_t blocked;
/* block the signal used by the timer */
// REMOVE THE COMMENTS BELOW
// sigemptyset(&blocked);
// sigaddset(&blocked, SIGUSR1);
// pthread_sigmask(SIG_BLOCK, &blocked, NULL);
/* initializes the thread attribute */
pthread_attr_init(&myattr);
pthread_attr_setinheritsched(&myattr, PTHREAD_EXPLICIT_SCHED);
pthread_attr_setschedpolicy(&myattr, SCHED_FIFO);
myparam.sched_priority = 3;
pthread_attr_setschedparam(&myattr, &myparam);
printf("starting a periodic thread...\n");
if (pthread_create(&mythread, &myattr, my_periodic_thread, NULL))
abort_perror("pthread_create");
pthread_attr_destroy(&myattr);
/* wait the end of the thread we just created */
pthread_join(mythread, &returnvalue);
printf("ending main...\n");
return 0;
}
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
[Xenomai-help] Newbie question about priorities of xenomai Threads
Dear all, My name is Paolo and i am brand new to Xenomai :-) I downloaded and installed the stable version of Xenomai, 2.0.1. I tried a few demos, and some POSIX skin examples: they work just fine :-). Then and I started reading the documentation and some code (I have to say it is very well done). Sorry if my first questions will be a little bit simple and obvious. I have a first question related to Xenomai Threads priorities and scheduling. In particular I refer to the "Common priority scheme" in the "Life with Adeos" document. What I understood is the following: - Xenomai threads have a priority value that is compatible (let's say transparent) between the primary and secondary domain. - Xenomai threads in secondary mode and Linux real time threads (let's say those with SCHED_FIFO or SCHED_RR policy) have compatible priority values. - Among the pool of ready Xenomai threads, the Xenomai thread with highest priority is scheduled first. - If the selected xenomai thread is in secondary mode and there is a Linux thread with higher priority, the Linux thread is scheduled first. First example: - Suppose that at a rescheduling we have the following thread in the ready queues - High Priority -> Linux thread H - Medium Priority -> Xenomai thread M in PRIMARY domain - Low Priority -> Xenomai thread L in primary domain Then, the Xenomai scheduler will select M, and M will be dispatched. Second example: -- - High Priority -> Linux thread H - Medium Priority -> Xenomai thread M in SECONDARY domain - Low Priority -> Xenomai thread L in primary domain Then, the Xenomai scheduler will select M. but M is in secondary mode, which means the Linux kernel will be scheduled. The Linux scheduler knows H (it's a linux thread), M (it's in secondary mode), and maybe about L (if it has been created by UVMs). The Linux scheduler will choose H, and H will be scheduled. Is that right? bye Paolo Gai http://www.evidence.eu.com
[Xenomai-help] Xenomai 2.0.1 - Posix Skin - realtime priorities - what I'm doing wrong?
Dear all, First of all, I would like to thank Philippe for the long and exaustive reply to my previous post about the scheduling example. I'm now trying the POSIX skin to write a very simple example using real-time priorities, RR and FIFO scheduling. The idea is that a high priority task creates two medium priority tasks (that just prints something using printf) and a low priority task (that prints a message). The example is run twice, in one case the medium priority tasks have SCHED_FIFO, in another case they have SCHED_RR. I would expect that in both cases the two medium priority tasks would run printing their characters (either in a FIFO order or mixed when using RR), and at their end the low priority task would have run printing its message. Instead, both with and without Xenomai, I obtain an output similar to the following one. -- [EMAIL PROTECTED] xenomai-demos]# ./ex_rr #LOW priority thread!!! ...###......###...######...###........##...###...###...###.#.....#LOW priority thread!!! [EMAIL PROTECTED] xenomai-demos]# -- I attach the source code of the example... Does the behavior I obtain is normal? What I'm doing wrong? bye Paolo example.tbz2 Description: Binary data
Re: [Xenomai-help] Xenomai 2.0.1 - Posix Skin - realtime priorities - what I'm doing wrong?
Dear Gilles,
Thanks again for the answer...
Gilles Chanteperdrix wrote:
[...]
What happens for certain is that the access to stdout buffer, when
compiling with the -D_REENTRANT flag, is serialized with a GNU libc
POSIX mutex. This account for the consistent behaviour between GNU libc
libpthread, or Xenomai POSIX skin library. The scheduling order is the
one of the libc POSIX library, and knowing exactly what happens would
require further investigation (there may be a difference between NPTL
and linuxthreads for example).
yes, I agree that mutexes called inside stdout primitives could change
the behavior of the scheduler... and that understanding what really
happens in this case is probably out of the scope of the mailing list.
Working around this issue means using calls to unlocked versions of libc
functions protected with Xenomai POSIX mutexes, such as, for example,
myputs and myputchar (sufficient for Paolo example) defined as :
[...]
Ok! I tried it, and I also tried another slightly modified version of
the demo, that simply replaces putchars with an unprotected array of
chars (let's suppose there are no race conditions) that is printed out
to stdout at the end of the game.
the results are the following, where the first part is RR and the second
is FIFO (it's quite strange for me that FIFO has more contect changes
than RR (?))
[EMAIL PROTECTED] xenomai-demos]# ./rt_ex_rr2
##L...###.###....
...###L.......#..##.#.#.#.#.###.#.####.##
and, moreover, another strange thing is that the threads does not call
any primitive...!!!
(I attach the two modified examples)
Now, your answer yields another important question: are domain
migrations inocuous from a scheduling point of view ?
Intuitively, if two tasks A and B in the same priority group are
runnable, and task A undergoes a migration from secondary to primary,
followed by a migration from primary to secondary without a suspension,
the scheduling order will be wrong.
The reason for this behaviour is that when task A migrates from
primary mode to secondary mode and will be waken up in Linux scheduler,
it should be put at the end of its priority group, so that B should
become the running task.
In short, the two successive migrations are equivalent to calling
sched_yield() from Linux scheduler point of view.
Ok, seems reasonable from the Xenomai point of view, excepts that users
should be aware of this behavior since they may make assumptions on the
non-preemptability at a given priority level of a particular piece of
code...
bye
Paolo
#include
#include
#include
/* for sched_param.c */
#include
/* */
/* unprotected buffer to avoid migrations */
char buf[1];
volatile char *buf_current=buf;
void myputchar(char c)
{
*buf_current++ = c;
}
void myprintbuf(void)
{
*buf_current=0;
puts(buf);
}
/* */
void *low(void *arg)
{
myputchar('L');
return NULL;
}
void *medium(void *arg)
{
int i,j;
for (i=0; i<300; i++) {
for (j=0; j<100; j++) ;
myputchar(((char *)arg)[0]);
}
return NULL;
}
void my_create(int policy)
{
pthread_t th1, th2, th3;
pthread_attr_t medium_attr, low_attr;
struct sched_param medium_policy, low_policy;
pthread_attr_init(&medium_attr);
pthread_attr_setschedpolicy(&medium_attr, policy);
medium_policy.sched_priority = 2;
pthread_attr_setschedparam(&medium_attr, &medium_policy);
pthread_attr_init(&low_attr);
pthread_attr_setschedpolicy(&low_attr, SCHED_FIFO);
low_policy.sched_priority = 1;
pthread_attr_setschedparam(&low_attr, &low_policy);
pthread_create(&th1, &medium_attr, medium, (char *)".");
pthread_create(&th2, &medium_attr, medium, (char *)"#");
pthread_create(&th3, &low_attr, low, NULL);
Re: [Xenomai-help] Xenomai 2.0.1 - Posix Skin - realtime priorities - what I'm doing wrong?
Gilles Chanteperdrix wrote: Paolo Gai wrote: > Gilles Chanteperdrix wrote: > >Working around this issue means using calls to unlocked versions of libc > >functions protected with Xenomai POSIX mutexes, such as, for example, > >myputs and myputchar (sufficient for Paolo example) defined as : > >[...] > > > > > Ok! I tried it, and I also tried another slightly modified version of > the demo, that simply replaces putchars with an unprotected array of > chars (let's suppose there are no race conditions) that is printed out > to stdout at the end of the game. There is no race condition in the SCHED_FIFO case or ahem, there should be none. Yes, that's true... Please also note that the "volatile" qualifier seem misplaced in your declaration of buf_current, it may matter since the compiler will probably inline calls to myputchar in the "medium" function, and buf_current will end up in a register. But this would have no effect only in the SCHED_FIFO case. Ouch! I just added it in the last tries and I forgot to remove it - sorry; However, I checked the source code produced by the compiler on i386 with the default compiler of FC3 and the code produced is the same with and without volatile; > the results are the following, where the first part is RR and the second > is FIFO (it's quite strange for me that FIFO has more contect changes > than RR (?)) Please also note that any thread created with the SCHED_RR attribute will be a plain Linux thread, and due to a bug in glibc, the thread will use the default policy. The results are strange indeed for SCHED_FIFO, it may be a bug, this needs a closer look... Maybe threads are not Xenomai threads using SCHED_FIFO policy at all ? Ok... I've done some more experiments. here are some results, with screenshots :-) First thing, I found this snippet http://sources.redhat.com/ml/glibc-bugs/2004-05/msg3.html that shows how on Linux and NPTL setting realtime priorities simply fails... I tried it on my FC3, and the behavior is the same, confirming the bug on my distro. Then, I slightly modified the example of the previous posts, setting the thread priorities with pthread_setschedparam. Case 1/Linux: Printing on the console using stdio, Linux real-time threads Screenshot: [EMAIL PROTECTED] xenomai-demos]# ./ex_rr3 thread id = 0xb7f0dbb0, policy = SCHED_OTHER, priority = 0 thread id = 0xb7f0dbb0, policy = SCHED_RR, priority = 3 ...###...###...###...###...###...######......###...###...###...###...###...######......###...###...###.#LOW priority thread!!! LOW priority thread!!! [EMAIL PROTECTED] xenomai-demos]# everything is fine, SCHED_RR and SCHED_FIFO works as expected, while the demo runs the XServer is freezed. Case 1/Xenomai: Printing on the console using stdio, Xenomai real-time threads Screenshot: [EMAIL PROTECTED] xenomai-demos]# ./rt_ex_rr3 thread id = 0xb7fc7bb0, policy = SCHED_OTHER, priority = 0 pthread_setschedparam failed: Success thread id = 0xb7fc7bb0, policy = SCHED_OTHER, priority = 0 pthread_
Re: [Xenomai-help] Xenomai 2.0.1 - Posix Skin - realtime priorities - what I'm doing wrong?
Ok, after having clicked ion the send button, I also discovered that
NPTL uses INHERIT_SCHED by default in the pthread attributes
http://sources.redhat.com/bugzilla/show_bug.cgi?id=145
I added it to the original examples, and I obtained the following
(basically it is similar to the Case 1 depicted before...)
Linux Real-Time Threads
[EMAIL PROTECTED] xenomai-demos]# ./ex_rr
LOW priority thread!!!
...###...###...###...###...###...###...###...###...###...###...###...###...###...###...###...###...###.#LOW
priority thread!!!
[EMAIL PROTECTED]
xenomai-demos]#
--> that's fine;
Xenomai Threads:
[EMAIL PROTECTED] xenomai-demos]# ./rt_ex_rr
LOW priority thread!!!
.######...######LOW
priority thread!!!
[EMAIL PROTECTED]
xenomai-demos]#
That is not what should be :-(
Again, in this case there may be an additional influence of using the
stdio with mutexes and so on...
bye
Paolo
/*
* Linux FIFO/RR scheduler demo
*
* This demo creates a few tasks scheduled with the SCHED_FIFO or the
* SCHED_RR scheduler
*
* Copyright (C) 2002 by Paolo Gai
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
#include
#include
#include
/* for sched_param.c */
#include
void *low(void *arg)
{
printf("LOW priority thread!!!\n");
return NULL;
}
void *medium(void *arg)
{
int i,j;
for (i=0; i<300; i++) {
for (j=0; j<100; j++) ;
printf((char *)arg);
}
return NULL;
}
void my_create(int policy)
{
pthread_t th1, th2, th3;
pthread_attr_t medium_attr, low_attr;
struct sched_param medium_policy, low_policy;
pthread_attr_init(&medium_attr);
pthread_attr_setinheritsched(&medium_attr, PTHREAD_EXPLICIT_SCHED);
pthread_attr_setschedpolicy(&medium_attr, policy);
medium_policy.sched_priority = 2;
pthread_attr_setschedparam(&medium_attr, &medium_policy);
pthread_attr_init(&low_attr);
pthread_attr_setinheritsched(&medium_attr, PTHREAD_EXPLICIT_SCHED);
pthread_attr_setschedpolicy(&low_attr, SCHED_FIFO);
low_policy.sched_priority = 1;
pthread_attr_setschedparam(&low_attr, &low_policy);
pthread_create(&th1, &medium_attr, medium, (char *)".");
pthread_create(&th2, &medium_attr, medium, (char *)"#");
pthread_create(&th3, &low_attr, low, NULL);
pthread_attr_destroy(&medium_attr);
pthread_attr_destroy(&low_attr);
pthread_join(th1, NULL);
pthread_join(th2, NULL);
pthread_join(th3, NULL);
}
void *high(void *arg)
{
/* first experiment:
- two medium priority thread scheduled with RR
- one low priority thread scheduled with FIFO
*/
my_create(SCHED_RR);
/* second experiment:
- two medium priority thread scheduled with FIFO
- one low priority thread scheduled with FIFO
*/
my_create(SCHED_FIFO);
return NULL;
}
int main()
{
pthread_t mythread;
pthread_attr_t myattr;
struct sched_param myparam;
[Xenomai-help] Xenomai 2.0.1 - Posix Skin - implementing a periodic thread
Dear all,
here is another small demo... this time of a periodic thread in POSIX.
It works under Xenomai, but it fails under Posix Real-Time.
The reason of the failure is the SIGUSR1 not being blocked by the main
thread. If in main() the comments below the note "// REMOVE THE COMMENTS
BELOW" are removed, then the signal is masked also in the main(), and as
a result the POSIX version works.
The question I have is if the behavior in Xenomai (that is, not failing
like the POSIX counterpart) is correct or not...
bye
Paolo
--
Evidence S.R.L. - Paolo Gai, CEO
http://www.evidence.eu.com Tel: +39 0587 274823 Fax: +39 0587 291904
#include
#include
#include
#include
#include
#include
#include
void abort_perror(const char *msg)
{
perror(msg);
exit(1);
}
void *my_periodic_thread (void *cookie)
{
struct itimerspec its;
struct sigevent sig;
sigset_t blocked;
siginfo_t si;
timer_t mytimer;
int i;
/* create a timer that will be used to periodically send a signal */
sig.sigev_notify = SIGEV_SIGNAL;
sig.sigev_signo = SIGUSR1;
sig.sigev_value.sival_ptr = &sig;
if(timer_create(CLOCK_REALTIME, &sig, &mytimer))
abort_perror("timer_create");
/* block the signal used by the timer */
sigemptyset(&blocked);
sigaddset(&blocked, SIGUSR1);
pthread_sigmask(SIG_BLOCK, &blocked, NULL);
/* set the periodic timer */
its.it_value.tv_sec = 0;
its.it_value.tv_nsec = 4000; /* 40 ms */
its.it_interval.tv_sec = 0;
its.it_interval.tv_nsec = 2000; /* 20 ms */;
if(timer_settime(mytimer, 0, &its, NULL))
abort_perror("timer_settime");
printf("periodic thread started...\n");
for (i=0; i<40; i++) {
while (sigwaitinfo(&blocked, &si) == -1 && errno == EINTR);
/* The thread body */
printf("%d\n",i);
}
printf("...periodic thread end!\n");
timer_delete(mytimer);
return NULL;
}
int main()
{
pthread_t mythread;
pthread_attr_t myattr;
struct sched_param myparam;
void *returnvalue;
sigset_t blocked;
/* block the signal used by the timer */
// REMOVE THE COMMENTS BELOW
// sigemptyset(&blocked);
// sigaddset(&blocked, SIGUSR1);
// pthread_sigmask(SIG_BLOCK, &blocked, NULL);
/* initializes the thread attribute */
pthread_attr_init(&myattr);
pthread_attr_setinheritsched(&myattr, PTHREAD_EXPLICIT_SCHED);
pthread_attr_setschedpolicy(&myattr, SCHED_FIFO);
myparam.sched_priority = 3;
pthread_attr_setschedparam(&myattr, &myparam);
printf("starting a periodic thread...\n");
if (pthread_create(&mythread, &myattr, my_periodic_thread, NULL))
abort_perror("pthread_create");
pthread_attr_destroy(&myattr);
/* wait the end of the thread we just created */
pthread_join(mythread, &returnvalue);
printf("ending main...\n");
return 0;
}
