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.


Attachment: signature.asc
Description: OpenPGP digital signature

Xenomai-core mailing list

Reply via email to