[Xenomai-help] Xenomai 2.0.1 - Posix Skin - realtime priorities - what I'm doing wrong?

[Xenomai-help] Xenomai 2.0.1 - Posix Skin - realtime priorities - what I'm doing wrong?

[Paolo Gai]

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

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.

----------------------------------------------------------
[root@domain.hid xenomai-demos]# ./ex_rr
#####LOW priority thread!!!
...........###########...........############...........###########...........###########............###########...........###########...........############..........########........########........########........########...........##########............############...........###########...........###########...........###########............####################........................########################.........................########################........................#########################.........................########################......................############..#LOW 
priority thread!!!
.......########........########.........#########.......########........########.........#########.......#######........########........#########........########........########.........#########........#######........########.........#########........########.......########.........########........########........########.........#########........................#########################.........................########################.......................######################.................................############################################.......................############[root@domain.hid 
xenomai-demos]#
----------------------------------------------------------

I attach the source code of the example...

Does the behavior I obtain is normal? What I'm doing wrong?

bye

Paolo


[-- Attachment #2: example.tbz2 --]
[-- Type: application/octet-stream, Size: 1795 bytes --]

Re: [Xenomai-help] Xenomai 2.0.1 - Posix Skin - realtime priorities - what I'm doing wrong?

[Ulrich Schwab]

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 : info@domain.hid
  web:   www.inmess.de
====================================================

[Xenomai-help] Boot problem V2.0.1 with Kernel 2.6.12

[Stephan Zimmermann]

Hello all,
I am facing a Problem with Xenomai 2.0.1 on Kernel 2.6.12. Based on my working 
config, I have patched the Kernel and recompiled. Now the System hangs at 
startup. There is no errormessage or so.

---snip---
Starting hotplug subsystem
	pci
---snap---

It is a Debian 3.1 system, running on a Centrino Notebook. 

I tried to disable PCI Hotplugging, but it gives me the same result. Disabling 
ADEOS Support gives me back my working System. 
And there is also something confusing the kernel build system, since patching 
it always recompiles every single file, making debugging not much fun :(

Are there any suggestions on tracking this down?


Have a nice Weekend,
Stephan

Re: [Xenomai-help] Xenomai 2.0.1 - Posix Skin - realtime priorities - what I'm doing wrong?

[Gilles Chanteperdrix]

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?

[Paolo Gai]

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

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 (?))

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

[-- Attachment #2: ex_rr2.c --]
[-- Type: text/x-csrc, Size: 2496 bytes --]

#include <stdio.h>
#include <pthread.h>
#include <stdlib.h>

/* for sched_param.c */
#include <sched.h> 

/* ------------------------------------------------------------ */
/* unprotected buffer to avoid migrations */

char buf[10000];
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<1000000; 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);
  
  pthread_attr_destroy(&medium_attr);
  pthread_attr_destroy(&low_attr);

  pthread_join(th1, NULL);
  pthread_join(th2, NULL);
  pthread_join(th3, NULL);
  
  myputchar(' ');
  myputchar(' ');
  myputchar(' ');
}


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;
  void *returnvalue;


  /* initializes the thread attribute */
  pthread_attr_init(&myattr);
  pthread_attr_setschedpolicy(&myattr, SCHED_FIFO);
  myparam.sched_priority = 3;
  pthread_attr_setschedparam(&myattr, &myparam);

  err = pthread_create(&mythread, &myattr, high, NULL);

  if (err) {
    perror("ERROR");
    exit(1);
  }

  pthread_attr_destroy(&myattr);

  /* wait the end of the thread we just created */
  pthread_join(mythread, &returnvalue);

  myprintbuf();

  return 0;
}


[-- Attachment #3: ex_rr.c --]
[-- Type: text/x-csrc, Size: 2292 bytes --]


#include <stdio.h>
#include <pthread.h>
#include <stdlib.h>

/* for sched_param.c */
#include <sched.h> 



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;
}

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<1000000; j++) ;
    myputchar(*(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_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);
  
  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;
  void *returnvalue;

  /* initializes the thread attribute */
  pthread_attr_init(&myattr);
  pthread_attr_setschedpolicy(&myattr, SCHED_FIFO);
  myparam.sched_priority = 3;
  pthread_attr_setschedparam(&myattr, &myparam);

  err = pthread_create(&mythread, &myattr, high, NULL);

  if (err) {
    perror("ERROR");
    exit(1);
  }

  pthread_attr_destroy(&myattr);

  /* wait the end of the thread we just created */
  pthread_join(mythread, &returnvalue);

  return 0;
}

Re: [Xenomai-help] Xenomai 2.0.1 - Posix Skin - realtime priorities - what I'm doing wrong?

[Gilles Chanteperdrix]

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.

Re: [Xenomai-help] Xenomai 2.0.1 - Posix Skin - realtime priorities - what I'm doing wrong?

[Paolo Gai]

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

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/msg00003.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:
[root@domain.hid 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!!!
[root@domain.hid 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:
[root@domain.hid 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!!!
##################################################################################################....................................................................................................##################################################################################################................................................................................................################################################################################################...............................................................................................................................................................................................................................................................................................................................................................................................................############################################################################################################################################################################################################################################################################################################LOW 
priority thread!!!
[root@domain.hid xenomai-demos]#

1) why do i get "pthread_setschedparam failed: Success" ?? Why the 
policy is not changed (am I still calling the Linux functions?)
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...
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!!!

----------------------------

Case 2/Linux: Printing on the console using a shared buffer, Linux 
real-time threads

Screenshot:
[root@domain.hid xenomai-demos]# ./ex_rr4
thread id = 0xb7fcabb0, policy = SCHED_OTHER, priority = 0
thread id = 0xb7fcabb0, policy = SCHED_RR, priority = 3
.............############...........###########...........###########...........############............###########...........###########...........############............###########...........###########...........###########............############...........###########...........###########...........############............###########...........###########...........############............###########...........###########............############...........###########...........############............###########...........###########...........############............###########....#####L   
............................................................................................................................................................................................................................................................................................................############################################################################################################################################################################################################################################################################################################L
[root@domain.hid xenomai-demos]#

works as expected, the same behavior as Case1/Linux.

----------------------------

Case 2/xenomai: Printing on the console using a shared buffer, Xenomai 
real-time threads

Screenshot:
[root@domain.hid xenomai-demos]# ./rt_ex_rr4
thread id = 0xb7f25bb0, policy = SCHED_OTHER, priority = 0
pthread_setschedparam failed: Success
thread id = 0xb7f25bb0, policy = SCHED_OTHER, priority = 0
pthread_setschedparam failed: Success
pthread_setschedparam failed: Success
...............#############L................................................................................................................................................................##################################################################################################################################################################.............................................................................................................................#############################################################################################################################   
............................................................................................................................................................................................................................................................................................................############################################################################################################################################################################################################################################################################################################L
[root@domain.hid xenomai-demos]#

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
- the SCHED_RR maybe still has some problems (???)



ok, that's all for now, sorry again for the long mail.

Paolo

[-- Attachment #2: ex_rr3.c --]
[-- Type: text/x-csrc, Size: 3584 bytes --]

/*
 * this version uses pthread_setschedparam as a workaround of the
 * glibc bug, prints using stdio
 */


#include <string.h>
#include <stdio.h>
#include <pthread.h>
#include <stdlib.h>

/* for sched_param.c */
#include <sched.h> 

/* --------------------------------------------- */
/* source from http://sources.redhat.com/ml/glibc-bugs/2004-05/msg00003.html */

#define LPRIO  1
#define MPRIO  2
#define HPRIO 3

void show_sched(void)
{
	struct sched_param sp;
	int policy;
	const char *pstr;
	
	if (pthread_getschedparam(pthread_self(), &policy, &sp) != 0) {
		perror("pthread_getschedparam failed");
		return;
	}

	switch(policy) {
		case SCHED_OTHER:
			pstr = "SCHED_OTHER";
			break;
		case SCHED_FIFO:
			pstr = "SCHED_FIFO";
			break;
		case SCHED_RR:
			pstr = "SCHED_RR";
			break;
		default:
			pstr = "unknown";
	}

	printf("thread id = 0x%lx, policy = %s, priority = %d\n",
			pthread_self(), pstr, sp.sched_priority);

	return;
}

void set_sched(int policy, int priority)
{
	struct sched_param schedp;

	memset(&schedp, 0, sizeof(schedp));
	schedp.sched_priority = priority;
	if (pthread_setschedparam(pthread_self(), policy, &schedp) != 0)
		perror("pthread_setschedparam failed");

}

/* --------------------------------------------- */



void *low(void *arg)
{
  set_sched(SCHED_FIFO, LPRIO);
  printf("LOW priority thread!!!\n");
  return NULL;
}

struct medium_par_t {
  int policy;
  char *c;
} mp1, mp2;

void *medium(void *arg)
{
  int i,j;

  struct medium_par_t *p = (struct medium_par_t *)arg;

  set_sched(p->policy, MPRIO);

  for (i=0; i<300; i++) {
    for (j=0; j<1000000; j++) ;
    printf(p->c);
  }

  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);

  mp1.policy = mp2.policy = policy;
  mp1.c = ".";
  mp2.c = "#";

  pthread_create(&th1, &medium_attr, medium, (void *)&mp1);
  pthread_create(&th2, &medium_attr, medium, (void *)&mp2);
  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)
{
  show_sched();
  set_sched(SCHED_RR, HPRIO);
  show_sched();

  /* 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 */
  pthread_attr_init(&myattr);
  pthread_attr_setschedpolicy(&myattr, SCHED_FIFO);
  myparam.sched_priority = 3;
  pthread_attr_setschedparam(&myattr, &myparam);

  err = pthread_create(&mythread, &myattr, high, (void *)&parameter);

  if (err) {
    perror("ERROR");
    exit(1);
  }

  pthread_attr_destroy(&myattr);

  /* wait the end of the thread we just created */
  pthread_join(mythread, &returnvalue);

  return 0;
}


[-- Attachment #3: ex_rr4.c --]
[-- Type: text/x-csrc, Size: 3954 bytes --]

/*
 * this version uses pthread_setschedparam as a workaround of the
 * glibc bug, prints using a shared buffer
 */

#include <stdio.h>
#include <pthread.h>
#include <stdlib.h>
#include <string.h>

/* for sched_param.c */
#include <sched.h> 


/* --------------------------------------------- */
/* source from http://sources.redhat.com/ml/glibc-bugs/2004-05/msg00003.html */

#define LPRIO  1
#define MPRIO  2
#define HPRIO 3

void show_sched(void)
{
	struct sched_param sp;
	int policy;
	const char *pstr;
	
	if (pthread_getschedparam(pthread_self(), &policy, &sp) != 0) {
		perror("pthread_getschedparam failed");
		return;
	}

	switch(policy) {
		case SCHED_OTHER:
			pstr = "SCHED_OTHER";
			break;
		case SCHED_FIFO:
			pstr = "SCHED_FIFO";
			break;
		case SCHED_RR:
			pstr = "SCHED_RR";
			break;
		default:
			pstr = "unknown";
	}

	printf("thread id = 0x%lx, policy = %s, priority = %d\n",
			pthread_self(), pstr, sp.sched_priority);

	return;
}

void set_sched(int policy, int priority)
{
	struct sched_param schedp;

	memset(&schedp, 0, sizeof(schedp));
	schedp.sched_priority = priority;
	if (pthread_setschedparam(pthread_self(), policy, &schedp) != 0)
		perror("pthread_setschedparam failed");

}

/* --------------------------------------------- */



/* ------------------------------------------------------------ */
/* unprotected buffer to avoid migrations */

char buf[10000];
char *buf_current=buf;

void myputchar(char c)
{
  *buf_current++ = c;
}

void myprintbuf(void)
{
  *buf_current=0;
  puts(buf);
}
/* ------------------------------------------------------------ */


void *low(void *arg)
{
  set_sched(SCHED_FIFO, LPRIO);
  myputchar('L');
  return NULL;
}

struct medium_par_t {
  int policy;
  char *c;
} mp1, mp2;

void *medium(void *arg)
{
  int i,j;

  struct medium_par_t *p = (struct medium_par_t *)arg;

  set_sched(p->policy, MPRIO);

  for (i=0; i<300; i++) {
    for (j=0; j<1000000; j++) ;
    myputchar(p->c[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);

  mp1.policy = mp2.policy = policy;
  mp1.c = ".";
  mp2.c = "#";

  pthread_create(&th1, &medium_attr, medium, (void *)&mp1);
  pthread_create(&th2, &medium_attr, medium, (void *)&mp2);
  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);
  
  myputchar(' ');
  myputchar(' ');
  myputchar(' ');
}


void *high(void *arg)
{
  show_sched();
  set_sched(SCHED_RR, HPRIO);
  show_sched();

  /* 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;
  void *returnvalue;


  /* initializes the thread attribute */
  pthread_attr_init(&myattr);
  pthread_attr_setschedpolicy(&myattr, SCHED_FIFO);
  myparam.sched_priority = 3;
  pthread_attr_setschedparam(&myattr, &myparam);

  err = pthread_create(&mythread, &myattr, high, NULL);

  if (err) {
    perror("ERROR");
    exit(1);
  }

  pthread_attr_destroy(&myattr);

  /* wait the end of the thread we just created */
  pthread_join(mythread, &returnvalue);

  myprintbuf();

  return 0;
}

Re: [Xenomai-help] Boot problem V2.0.1 with Kernel 2.6.12

[Philippe Gerum]

Stephan Zimmermann wrote:
> Hello all,
> I am facing a Problem with Xenomai 2.0.1 on Kernel 2.6.12. Based on my working 
> config, I have patched the Kernel and recompiled. Now the System hangs at 
> startup. There is no errormessage or so.
>

The Adeos patch for 2.6.12 is an oldgen one; it is known to be bugous 
for certain hw configurations, causing boot lockup. The best way to 
solve this is to upgrade to 2.6.13 or preferably 2.6.14, and use a 
recent newgen (ipipe) patch available here: 
http://download.gna.org/adeos/patches/v2.6/adeos/i386/


> ---snip---
> Starting hotplug subsystem
> 	pci
> ---snap---
> 
> It is a Debian 3.1 system, running on a Centrino Notebook. 
> 
> I tried to disable PCI Hotplugging, but it gives me the same result. Disabling 
> ADEOS Support gives me back my working System. 
> And there is also something confusing the kernel build system, since patching 
> it always recompiles every single file, making debugging not much fun :(
> 
> Are there any suggestions on tracking this down?
> 
> 
> Have a nice Weekend,
> Stephan
> 
> 
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
> 


-- 

Philippe.

Re: [Xenomai-help] Xenomai 2.0.1 - Posix Skin - realtime priorities - what I'm doing wrong?

[Paolo Gai]

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

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

[root@domain.hid xenomai-demos]# ./ex_rr
LOW priority thread!!!
...........###########............############...........###########...........###########............############...........###########............############...........###########...........###########............############...........###########...........###########............############...........###########...........###########............############...........###########............############...........###########...........###########............############...........###########...........###########............############...........###########...........###########.....#####LOW 
priority thread!!!
............................................................................................................................................................................................................................................................................................................############################################################################################################################################################################################################################################################################################################[root@domain.hid
xenomai-demos]#

--> that's fine;

Xenomai Threads:

[root@domain.hid xenomai-demos]# ./rt_ex_rr
LOW priority thread!!!
.....###................................................................................###############################################################################...............................................................................################################################################################................................................................................###############################################################################........................................................###########################################################............................................................................................................................................................................................................................................................................................................LOW 
priority thread!!!
############################################################################################################################################################################################################################################################################################################[root@domain.hid
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



[-- Attachment #2: ex_rr.c --]
[-- Type: text/x-csrc, Size: 3221 bytes --]

/*
 * 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; i<300; i++) {
    for (j=0; j<1000000; 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 */
  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);

  err = pthread_create(&mythread, &myattr, high, (void *)&parameter);

  if (err) {
    perror("ERROR");
    exit(1);
  }

  pthread_attr_destroy(&myattr);

  /* wait the end of the thread we just created */
  pthread_join(mythread, &returnvalue);

  return 0;
}

Re: [Xenomai-help] Xenomai 2.0.1 - Posix Skin - realtime priorities - what I'm doing wrong?

[Gilles Chanteperdrix]

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.