Re: [Xenomai-help] Xenomai 2.0.1 - Posix Skin - realtime priorities - what I'm doing wrong?
Paolo Gai wrote: (...) 1) why do i get pthread_setschedparam failed: Success ?? Why the policy is not changed (am I still calling the Linux functions?) That one is a bug, fixed in the repository: it was due to the fact that PTHREAD_EXPLICIT_SCHED had different values in /usr/include/pthread.h and in Xenomai skins/posix/posix.h. Thanks for pointing this out. 2) The SCHED_FIFO seems to work as expected, whereas SCHED_RR seems to have a strange behavior when it starts (the low priority thread is started before the others... Because threads are started with the SCHED_OTHER policy and only change their policy once they call pthread_setschedparam. So, if by any chance the lowest priority thread is elected first, it becomes the only real-time thread by calling pthread_setschedparam, and since the mid-priority threads are not real-time yet, it runs before them. 3) the XServer freezes but for a SHORTER time - I guess they are the Xenomai threads, one thing I do not understand is why with Linux the XServer stops for around 10 seconds, and in Xenomai less than one second!!! Because the threads were running with the SCHED_OTHER policy, due to the bug in pthread_setschedparam. (...) Again, the same behavior as before in Case 1/Xenomai which make me think that - the behavior on Xenomai does not depend a lot on the fact i called stdio functions Yes, my mistake, as required by the standard, glibc pthread mutexes work as expected for SCHED_FIFO and SCHED_RR policies. - the SCHED_RR maybe still has some problems (???) SCHED_RR is not supported for Xenomai posix skin user-space threads. My understanding is that having round-robin scheduling work with xenomai threads in secondary mode requires changes in xnpod_announce_tick. -- Gilles Chanteperdrix. ___ 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?
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_setschedparam failed: Success pthread_setschedparam failed: Success .LOW priority thread!!!
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 stdio.h
#include pthread.h
#include stdlib.h
/* for sched_param.c */
#include sched.h
void *low(void *arg)
{
printf(LOW priority thread!!!\n);
return NULL;
}
void *medium(void *arg)
{
int i,j;
for (i=0; i300; i++) {
for (j=0; j100; 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;
int err;
int parameter;
void *returnvalue;
/* initializes the thread attribute */
[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?
On Friday 09 December 2005 15:33, Paolo Gai wrote: 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. I did not look inside Your code, but if You are using printf the threads will be switched back to secondary domain (non-RT), this might screw up the order of scheduling. You can try using a pipe to hand down the print output to a reader thread in secondary domain. This way Your threads in primary domain stay where they belong. So long, Ulrich Schwab -- inmess GmbH Frankfurter Str. 74 D - 64521 Gross-Gerau Phone: +49 6152 97790 Fax : +49 6152 977920 mail : [EMAIL PROTECTED] web: www.inmess.de ___ 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?
Ulrich Schwab wrote:
On Friday 09 December 2005 15:33, Paolo Gai wrote:
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.
I did not look inside Your code, but if You are using printf the threads
will
be switched back to secondary domain (non-RT), this might screw up the order
of scheduling.
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).
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 :
pthread_mutex_t xeno_stdout_lock;
int myputchar(int c)
{
int err;
pthread_mutex_lock(xeno_stdout_lock);
err = putchar_unlocked(c);
pthread_mutex_unlock(xeno_stdout_lock);
return err;
}
int myputs(const char *s)
{
int err;
pthread_mutex_lock(xeno_stdout_lock);
err = puts_unlocked(s);
pthread_mutex_unlock(xeno_stdout_lock);
return err;
}
defining myprintf is a bit more complicated if we want to avoid dynamic
allocation, and if we do not avoid dynamic allocation, malloc is
protected with another mutex, so we may run (less often, of course) into
a similar issue.
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.
--
Gilles Chanteperdrix.
___
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 stdio.h
#include pthread.h
#include stdlib.h
/* for sched_param.c */
#include sched.h
/* */
/* 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; i300; i++) {
for (j=0; j100; 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,
Re: [Xenomai-help] Xenomai 2.0.1 - Posix Skin - realtime priorities - what I'm doing wrong?
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. 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. 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 ? -- Gilles Chanteperdrix. ___ 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?
Ulrich Schwab wrote:
On Friday 09 December 2005 15:33, Paolo Gai wrote:
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.
I did not look inside Your code, but if You are using printf the threads
will
be switched back to secondary domain (non-RT), this might screw up the order
of scheduling.
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).
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 :
pthread_mutex_t xeno_stdout_lock;
int myputchar(int c)
{
int err;
pthread_mutex_lock(xeno_stdout_lock);
err = putchar_unlocked(c);
pthread_mutex_unlock(xeno_stdout_lock);
return err;
}
int myputs(const char *s)
{
int err;
pthread_mutex_lock(xeno_stdout_lock);
err = puts_unlocked(s);
pthread_mutex_unlock(xeno_stdout_lock);
return err;
}
defining myprintf is a bit more complicated if we want to avoid dynamic
allocation, and if we do not avoid dynamic allocation, malloc is
protected with another mutex, so we may run (less often, of course) into
a similar issue.
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.
--
Gilles Chanteperdrix.
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 stdio.h
#include pthread.h
#include stdlib.h
/* for sched_param.c */
#include sched.h
/* */
/* 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; i300; i++) {
for (j=0; j100; 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,
Re: [Xenomai-help] Xenomai 2.0.1 - Posix Skin - realtime priorities - what I'm doing wrong?
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. 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. 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 ? -- Gilles Chanteperdrix.
