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
