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