On 2011-09-11 12:50, Jan Kiszka wrote: > Hi all, > > just looked into the hrescnt issue again, specifically the corner case > of a shadow thread switching from real-time policy to SCHED_OTHER. > > Looks like we don't support this at all ATM: > > do_setsched_event ignores events that enabled SCHED_OTHER, and the > XNOTHER flag is only set on xnshadow_map, not updated anywhere else. > Fixing this is not straightforward as that flag resides in a state > variable that is owned by the thread (ie. updated non-atomically) while > do_setsched_event can also be called over different contexts.
OK, it just takes nklock to update the thread state. > > Or am I missing something? From __xnpod_set_thread_schedparam: "A non-real-time shadow may upgrade to real-time FIFO scheduling, but the latter may never downgrade to SCHED_NORMAL Xenomai-wise. In the valid case, we clear XNOTHER to reflect the change." What prevents us from setting XNOTHER if the priority drops to 0, i.e. the Linux task re-enters SCHED_NORMAL (while Xenomai will still schedule it via its RT class of course)? We cannot deny such a transition on the Linux side anyway, can we? Jan
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list Xenomaiemail@example.com https://mail.gna.org/listinfo/xenomai-core