Jan Kiszka wrote:
 > (..)
 > Now I wonder how to resolve this, how to make pthread_setschedparam (a
 > rather central RT-service) really real-time safe? I would say we need
 > something like a lazy schedparam propagation to Linux which only takes
 > place when the thread enters secondary mode intentionally or no other RT
 > thread is ready. But I do not have a design for this at hand. Nasty.

A simple solution is to wrap pthread_getschedparam as well. It would
fallback to __real_pthread_getschedparam when the xenomai posix skin
syscall returns -ESRCH. This would allow to remove the offending call to
__real_pthread_setschedparam in __wrap_pthread_setschedparam.

 > [My preferred way for every setup != CONFIG_PREEMPT_RT + CONFIG_XENOMAI
 > would still be to switch this prio-inheritance off for the root thread.
 > But this was nack'ed by Philippe several times before... ;)]
 > Side note: the native skin does not seem to suffer from this effect as
 > it only tracks the current prio at Xenomai level.
 > Jan
 > PS: Gilles, what about marking those services of the POSIX in the doc
 > that may issue a linux syscall (and under which conditions)?

Actually, syscalls that may be called only from a particular context or
that cause migration of their caller have a paragraph entitled "Valid
contexts", if pthread_setschedparam lack this paragraph, it is probably
because its implementation changed without its documentation.


                                            Gilles Chanteperdrix.

Xenomai-core mailing list

Reply via email to