Re: [Xenomai-core] Using SIGWINCH to trigger priority change.
Gilles Chanteperdrix wrote: > Philippe Gerum wrote: >> (*) Btw, if you happen to export the current thread state via the shared >> heap to >> userland for the fast mutexes, I guess that we could to use it as well to >> implement a smarter pthread_setschedparam/rt_task_set_priority, doing >> something >> like: >> >> if (in_secondary_mode(ptid)) >> __real_pthread_setschedparam(...); >> else >> XENOMAI_SKINCALL(...); >> >> When running in secondary mode, we should be able to rely on the automatic >> propagation the nucleus does in do_setsched_event(), if the underlying >> priority >> scale is POSIX-compatible, which will work for the native skin as well. > > If we export the thread state to user-space there are many things we can > do from user-space, such as disabling preemption for instance. > I'm unsure if this one deserves the burden of dealing with the nesting counter and rescheduling logic from userland. Disabling preemption in apps is something that looks fishy enough to refrain from optimizing the case. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Using SIGWINCH to trigger priority change.
Philippe Gerum wrote: > (*) Btw, if you happen to export the current thread state via the shared heap > to > userland for the fast mutexes, I guess that we could to use it as well to > implement a smarter pthread_setschedparam/rt_task_set_priority, doing > something > like: > > if (in_secondary_mode(ptid)) > __real_pthread_setschedparam(...); > else > XENOMAI_SKINCALL(...); > > When running in secondary mode, we should be able to rely on the automatic > propagation the nucleus does in do_setsched_event(), if the underlying > priority > scale is POSIX-compatible, which will work for the native skin as well. If we export the thread state to user-space there are many things we can do from user-space, such as disabling preemption for instance. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Using SIGWINCH to trigger priority change.
Gilles Chanteperdrix wrote: > Hi, > > I am working on using SIGWINCH to trigger priority changes in > user-space. And I am afraid it will never really work: > - Xenomai makes a difference between the base priority of a thread and > its current priority. But pthread_getschedparam should return the base > priority, not the current priority, so, we need a way to change the > current priority of a thread without changing its base priority. > - I do not know at what time we should trigger a signal to the thread > whose priority is changing: > . if we send it as soon as we return to user-space (at the same time > as when we handle LO_RENICE_REQ), if the thread whose priority is > changing is not the current one, we potentially trigger a > primary/secondary mode transition for this thread; > . if we wait for the target thread to return to secondary mode (via > xnshadow_relax), any other thread in the same process which would read > the target thread priority with pthread_getschedparam would not see that > the priority has changed; > . we could do it as soon as a thread of the same process returns to > secondary mode, but it looks complicated, and besides, > pthread_getschedparam can safely be called from primary mode, so we > still have the same issue as for the previous point. > > This is where I stopped thinking about this idea. > Thanks in advance for any help. > Please go ahead with your ongoing implementation. AFAICT from the latest discussions, it is correct. The point is about how and when a change of thread priority level should be visible, nothing else. This means that: - we have to make sure that all Xenomai services will return the same priority value for any given thread at any point in time, which may have been set by a previous call to xnpod_renice_thread(), issued from whatever skin wrapper. - we have to make sure that for any given thread whose priority is changed from the Xenomai side, the glibc will reflect the priority change. - BUT, we can't guarantee that a priority change affecting a Xenomai RT thread that is done from _within_ the Xenomai realm, will be immediately visible from _outside_ of that realm; this means that if pthread_setschedparam() from the POSIX skin is used to change the priority of a RT thread, there is no guarantee that a call to __real_pthread_getschedparam() will see the change _immediately_ after. However, pthread_getschedparam() from the POSIX skin will see that change immediately. What we should guarantee though, is that a priority propagation will take place asap, when the affected thread moves back to secondary mode, so that our priority management remains logically correct. (*) In short, we have two kernels, and only asynchronous ways of propagating the changes between them, so there is no point in chasing wild gooses trying to have immediate visibility in all cases. (*) Btw, if you happen to export the current thread state via the shared heap to userland for the fast mutexes, I guess that we could to use it as well to implement a smarter pthread_setschedparam/rt_task_set_priority, doing something like: if (in_secondary_mode(ptid)) __real_pthread_setschedparam(...); else XENOMAI_SKINCALL(...); When running in secondary mode, we should be able to rely on the automatic propagation the nucleus does in do_setsched_event(), if the underlying priority scale is POSIX-compatible, which will work for the native skin as well. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Using SIGWINCH to trigger priority change.
Gilles Chanteperdrix wrote: > Hi, > > I am working on using SIGWINCH to trigger priority changes in > user-space. And I am afraid it will never really work: > - Xenomai makes a difference between the base priority of a thread and > its current priority. But pthread_getschedparam should return the base > priority, not the current priority, so, we need a way to change the > current priority of a thread without changing its base priority. > - I do not know at what time we should trigger a signal to the thread > whose priority is changing: > . if we send it as soon as we return to user-space (at the same time > as when we handle LO_RENICE_REQ), if the thread whose priority is > changing is not the current one, we potentially trigger a > primary/secondary mode transition for this thread; > . if we wait for the target thread to return to secondary mode (via > xnshadow_relax), any other thread in the same process which would read > the target thread priority with pthread_getschedparam would not see that > the priority has changed; > . we could do it as soon as a thread of the same process returns to > secondary mode, but it looks complicated, and besides, > pthread_getschedparam can safely be called from primary mode, so we > still have the same issue as for the previous point. > > This is where I stopped thinking about this idea. It would be nice to have pthread_getschedparam always in sync with the shadow base prio. But if this is obviously at least very complicated (if not infeasible), I would focus on getting the base prio right when the thread switches to secondary mode (or if it already is there, of course). That we cannot guarantee pthread_getschedparam returning the same value that rt_task_set_priority applied should simply be documented. Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
