[Xenomai-core] Using SIGWINCH to trigger priority change.

[Xenomai-core] Using SIGWINCH to trigger priority change.

[Gilles Chanteperdrix]

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.

-- 
					    Gilles.

Re: [Xenomai-core] Using SIGWINCH to trigger priority change.

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1820 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

Re: [Xenomai-core] Using SIGWINCH to trigger priority change.

[Philippe Gerum]

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.

Re: [Xenomai-core] Using SIGWINCH to trigger priority change.

[Gilles Chanteperdrix]

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.

Re: [Xenomai-core] Using SIGWINCH to trigger priority change.

[Philippe Gerum]

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.