[Xenomai-help] POSIX Skin: Changing scheduling parameters of threads in other processes

[Xenomai-help] POSIX Skin: Changing scheduling parameters of threads in other processes

[Torsten Kröger]

Hello everybody,

this is my first email to this list, and I would like to start with a
question. I use the posix skin of Xenomai 2.3.1, and I have several
processes running, each consisting of several threads. Is there a
possibility for a thread A1 running in process A to change the
scheduling parameters, in particular the priority, of a thread B1
running in process B?

Regarding the posix specification I cannot find this functionality there
and so I guess there is no way doing it with "pthread_setschedparam()".
But is there another possibility?  

Any kind of feedback will be appreciated.


Best regards from Braunschweig,
Torsten

Re: [Xenomai-help] POSIX Skin: Changing scheduling parameters of threads in other processes

[Gilles Chanteperdrix]

Torsten Kröger wrote:
 > Hello everybody,
 > 
 > this is my first email to this list, and I would like to start with a
 > question. I use the posix skin of Xenomai 2.3.1, and I have several
 > processes running, each consisting of several threads. Is there a
 > possibility for a thread A1 running in process A to change the
 > scheduling parameters, in particular the priority, of a thread B1
 > running in process B?
 > 
 > Regarding the posix specification I cannot find this functionality there
 > and so I guess there is no way doing it with "pthread_setschedparam()".
 > But is there another possibility?  

No, the only way you could do that is by using an IPC to pass the
request from a process to another. You could use message queues for
that.

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-help] POSIX Skin: Changing scheduling parameters ofthreads in other processes

[Torsten Kröger]

>> this is my first email to this list, and I would like to start with a
>> question. I use the posix skin of Xenomai 2.3.1, and I have several
>> processes running, each consisting of several threads. Is there a
>> possibility for a thread A1 running in process A to change the
>> scheduling parameters, in particular the priority, of a thread B1
>> running in process B?
>>
>> Regarding the posix specification I cannot find this functionality
there
>> and so I guess there is no way doing it with
"pthread_setschedparam()".
>> But is there another possibility?
>
>No, the only way you could do that is by using an IPC to pass the
>request from a process to another. You could use message queues for
>that.
>

Thanks for this immediate answer. I just read some parts of the posix
specification, and if I'm not mistaking posix message queues do not
inherit thread priorities. They only sort messages in (message-)priority
order. I guess you mean synchronous message passing provided by
rt_task_send(), rt_task_receive(), and rt_task_reply() in the native
API. This would of course be an alternative. But therefore I would have
to port many code to the native API. Would then be possible to let one
RT_TASK change the prioriy of any other RT_TASK by simply calling
rt_task_set_priority()? 

Regarding send/receive/reply messaging with the native API, I am not
sure if I detected a mistake in the implementation (file
ksrc/skins/native/task.c). When a sender RT_TASK sends a message to a
receiver RT_TASK, then the priority is only inherited, if the receiver's
priority is lower than the one of the sender. For my understanding, the
priority should be inherited in any case.

>From the reception of a message till the call of rt_task_reply() the
receiver RT_TASK works for the sender and should get its priority.
Otherwise we would have a priority inversion at this point, because any
RT_TASK with a priority between the sender and receiver priority would
now be blocked by the receiver (which works for the lower prioritized
sender at its old priority).


Many many thanks in advance for your help,
Torsten

Re: [Xenomai-help] POSIX Skin: Changing scheduling parameters ofthreads in other processes

[Gilles Chanteperdrix]

On 8/9/07, Torsten Kröger <t.kroeger@domain.hid> wrote:
> >> this is my first email to this list, and I would like to start with a
> >> question. I use the posix skin of Xenomai 2.3.1, and I have several
> >> processes running, each consisting of several threads. Is there a
> >> possibility for a thread A1 running in process A to change the
> >> scheduling parameters, in particular the priority, of a thread B1
> >> running in process B?
> >>
> >> Regarding the posix specification I cannot find this functionality
> there
> >> and so I guess there is no way doing it with
> "pthread_setschedparam()".
> >> But is there another possibility?
> >
> >No, the only way you could do that is by using an IPC to pass the
> >request from a process to another. You could use message queues for
> >that.
> >
>
> Thanks for this immediate answer. I just read some parts of the posix
> specification, and if I'm not mistaking posix message queues do not
> inherit thread priorities.

My idea was that you could encode the request in a message that you
would handle in the receiving process by receiving messages and
calling pthread_setschedparam.
But then another problem arises: a pthread_t identifier is only valid
in one process, so how could you designate in one process the threads
of another process ?

-- 
                                               Gilles Chanteperdrix

Re: [Xenomai-help] POSIX Skin: Changing scheduling parameters ofthreads in other processes

[Torsten Kröger]

>>>> this is my first email to this list, and I would like to start with
a
>>>> question. I use the posix skin of Xenomai 2.3.1, and I have several
>>>> processes running, each consisting of several threads. Is there a
>>>> possibility for a thread A1 running in process A to change the
>>>> scheduling parameters, in particular the priority, of a thread B1
>>>> running in process B?
>>>>
>>>> Regarding the posix specification I cannot find this functionality
>>>> there
>>>> and so I guess there is no way doing it with
>>>> "pthread_setschedparam()".
>>>> But is there another possibility?
>>>
>>>No, the only way you could do that is by using an IPC to pass the
>>>request from a process to another. You could use message queues for
>>>that.
>>>
>>
>> Thanks for this immediate answer. I just read some parts of the posix
>> specification, and if I'm not mistaking posix message queues do not
>> inherit thread priorities.
>
>My idea was that you could encode the request in a message that you
>would handle in the receiving process by receiving messages and
>calling pthread_setschedparam.

That was also one of my first ideas. But it won't be real-time-capable.
When a high-priority sender thread sends a message (using posix message
queues) to a low-priority receiver thread and blocks right after the
mq_send() call, then receiver thread should (immediately) get inherit
the high priority of the sender thread. But if there is any other
middle-priority thread in the ready queue, the scheduler would prefer
the middle-priority one instead of the receiver thread, which remains at
its low priority until it becomes scheduled. As result, we would have
the problem of priority inversion again, because the low-priority
receiver is supposed to work for the high-priority sender, i.e. it
should work with high priority.

So this won't work, I'd say.
 
>But then another problem arises: a pthread_t identifier is only valid
>in one process, so how could you designate in one process the threads
>of another process ?
>

I guess this is a general problem of the posix specification. As fare as
I know, there is no way to change the priority of a thread running in
another process. You would need something like SchedSet() from the
QNX-OS. Here you can specify a process ID and a thread ID in order to
change the thread's scheduling parameters.


Best regards and thanks for your _fast_ help again,
Torsten

Re: [Xenomai-help] POSIX Skin: Changing scheduling parameters ofthreads in other processes

[Gilles Chanteperdrix]

On 8/9/07, Torsten Kröger <t.kroeger@domain.hid> wrote:
> >> Thanks for this immediate answer. I just read some parts of the posix
> >> specification, and if I'm not mistaking posix message queues do not
> >> inherit thread priorities.
> >
> >My idea was that you could encode the request in a message that you
> >would handle in the receiving process by receiving messages and
> >calling pthread_setschedparam.
>
> That was also one of my first ideas. But it won't be real-time-capable.
> When a high-priority sender thread sends a message (using posix message
> queues) to a low-priority receiver thread and blocks right after the

I do not understand why you need pthread_setschedparam to happen with
a high priority, but anyway In the process that will receive the
messages, there will be a thread whose only job will be to receive
messages from the message queue. Why not giving this particular thread
the highest priority available ?


> I guess this is a general problem of the posix specification. As fare as
> I know, there is no way to change the priority of a thread running in
> another process. You would need something like SchedSet() from the
> QNX-OS. Here you can specify a process ID and a thread ID in order to
> change the thread's scheduling parameters.

The problem I see is, how in one process, do you know the thread ID of
a threa d belonging to another process. If you solve this issue in
your application, then  the message queue solution can work.

-- 
                                               Gilles Chanteperdrix

Re: [Xenomai-help] POSIX Skin: Changing scheduling parameters ofthreads in other processes

[Torsten Kröger]

>>>> Thanks for this immediate answer. I just read some parts of the
posix
>>>> specification, and if I'm not mistaking posix message queues do not
>>>> inherit thread priorities.
>>>
>>>My idea was that you could encode the request in a message that you
>>>would handle in the receiving process by receiving messages and
>>>calling pthread_setschedparam.
>>
>> That was also one of my first ideas. But it won't be
real-time-capable.
>> When a high-priority sender thread sends a message (using posix
message
>> queues) to a low-priority receiver thread and blocks right after the
>
>I do not understand why you need pthread_setschedparam to happen with
>a high priority, but anyway In the process that will receive the
>messages, there will be a thread whose only job will be to receive
>messages from the message queue. Why not giving this particular thread
>the highest priority available ?

That was also one of my next ideas. This has two significant
disadvantages. The first is that in such a case the receiver would
always be scheduled after reception of a message. When having more than
one thread running at the same priority of the sender, the scheduling
policy, round robin or fifo, would get disordered, because the receiver
thread would get scheduled for a very short time (until
pthread_setschedparam() is called). The second disadvantage would be
that the use of a time out (mq_timedreceive()) would lead also lead to
undesired system behavior. If mq_timedreceive() is called periodically
with a time out value of a very few ms for example, than it would
interrupt other threads, which actually have a higher priority, i.e. it
would lead to priority inversion for very short times (from the
reception of a message/time out till the call of
pthread_setschedparam()). Due to the effect of much more context
switches, this would also lead to a worse overall system performance.

In general, I agree, this might be a solution for the problem, but I'm
afraid that the resulting system behavior is not strictly deterministic,
because a low priority receiver thread might slow down high-priority
threads.

>
>> I guess this is a general problem of the posix specification. As fare
as
>> I know, there is no way to change the priority of a thread running in
>> another process. You would need something like SchedSet() from the
>> QNX-OS. Here you can specify a process ID and a thread ID in order to
>> change the thread's scheduling parameters.
>
>The problem I see is, how in one process, do you know the thread ID of
>a threa d belonging to another process. If you solve this issue in
>your application, then  the message queue solution can work.
>
I do this with shared memory. How are message queues implemented in the
posix skin? I had a look into the code (file ksrc/skins/posix/mq.c) and
there I could not find the part for thread priority inheritance (not
message priority). As I said, regarding the posix specs, posix message
queues do not apply priority inheritance, because a receiver thread
would get the priority of the sender for all the time, and there is not
necessarily a point, where the receiver would be set back to its base
priority.

As consequence, I'd guess, that message queues won't work here.


Kind regards and thanks for this - I think very nice - conversation,
Torsten

Re: [Xenomai-help] POSIX Skin: Changing scheduling parameters ofthreads in other processes

[Philippe Gerum]

On Thu, 2007-08-09 at 15:06 +0200, Torsten Kröger wrote:
> >> this is my first email to this list, and I would like to start with a
> >> question. I use the posix skin of Xenomai 2.3.1, and I have several
> >> processes running, each consisting of several threads. Is there a
> >> possibility for a thread A1 running in process A to change the
> >> scheduling parameters, in particular the priority, of a thread B1
> >> running in process B?
> >>
> >> Regarding the posix specification I cannot find this functionality
> there
> >> and so I guess there is no way doing it with
> "pthread_setschedparam()".
> >> But is there another possibility?
> >
> >No, the only way you could do that is by using an IPC to pass the
> >request from a process to another. You could use message queues for
> >that.
> >
> 
> Thanks for this immediate answer. I just read some parts of the posix
> specification, and if I'm not mistaking posix message queues do not
> inherit thread priorities. They only sort messages in (message-)priority
> order. I guess you mean synchronous message passing provided by
> rt_task_send(), rt_task_receive(), and rt_task_reply() in the native
> API. This would of course be an alternative. But therefore I would have
> to port many code to the native API. Would then be possible to let one
> RT_TASK change the prioriy of any other RT_TASK by simply calling
> rt_task_set_priority()? 
> 
> Regarding send/receive/reply messaging with the native API, I am not
> sure if I detected a mistake in the implementation (file
> ksrc/skins/native/task.c). When a sender RT_TASK sends a message to a
> receiver RT_TASK, then the priority is only inherited, if the receiver's
> priority is lower than the one of the sender. For my understanding, the
> priority should be inherited in any case.
> 
> >From the reception of a message till the call of rt_task_reply() the
> receiver RT_TASK works for the sender and should get its priority.
> Otherwise we would have a priority inversion at this point, because any
> RT_TASK with a priority between the sender and receiver priority would
> now be blocked by the receiver (which works for the lower prioritized
> sender at its old priority).
> 

You are supposed to pick the right base priority for the server in the
first place so this case never arises. Any other behaviour than the
strict priority inheritance protocol would be broken by design because a
server might sleep while processing a request and requests might pile up
(try with two senders having different priorities, highest priority
first, and server entering a blocked state in the middle of its
processing for the first request).

> 
> Many many thanks in advance for your help,
> Torsten
> 
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
-- 
Philippe.

Re: [Xenomai-help] POSIX Skin: Changing scheduling parameters of threads in other processes

[Torsten Kröger]

>>
>> Regarding send/receive/reply messaging with the native API, I am not
>> sure if I detected a mistake in the implementation (file
>> ksrc/skins/native/task.c). When a sender RT_TASK sends a message to a
>> receiver RT_TASK, then the priority is only inherited, if the
receiver's
>> priority is lower than the one of the sender. For my understanding,
the
>> priority should be inherited in any case.
>>
>> >From the reception of a message till the call of rt_task_reply() the
>> receiver RT_TASK works for the sender and should get its priority.
>> Otherwise we would have a priority inversion at this point, because
any
>> RT_TASK with a priority between the sender and receiver priority
would
>> now be blocked by the receiver (which works for the lower prioritized
>> sender at its old priority).
>>
>
>You are supposed to pick the right base priority for the server in the
>first place so this case never arises. Any other behaviour than the
>strict priority inheritance protocol would be broken by design because
a
>server might sleep while processing a request and requests might pile
up

I totally agree at first glance. When regarding the concepts based on
the work of Sha, Rajkumar, and Lehoczky ("Priority Inheritance
Protocols: An Approach to Real-Time Synchronization", IEEE Transactions
on Computers, Vol. 39, No. 9, 1990) you are generally right (I guess,
because I'm no expert). But in the particular case of "Synchronous
Message Passing" (send/receive/reply-messaging), I think the "QNX-way"
would make much more sense regarding real-time capabilities: Receivers
(servers) always inherit the priority of the senders (client), no matter
if the receiver's priority is lower or higher than the sender one's. A
description can be found here:

http://www.qnx.com/developers/docs/momentics621_docs/neutrino/sys_arch/k
ernel.html#NTOIPC

The major advantage is that priority inversion problems are completely
avoided here. As also described in the text above, are two rules, which
have to be observed:

1. You are not allowed to have two threads sending each other.
2. Threads must be arranged in a hierarchy, where send calls only go up.

When using the Xenomai native send/receive/reply calls, the system is
not real-time capable in general. The user always has to care for the
whole system, which really gets sophisticated in systems with a huge
number of threads/processes.

>(try with two senders having different priorities, highest priority
>first, and server entering a blocked state in the middle of its
>processing for the first request).

Regarding this example, I cannot see the problem. We won't have a
deadlock in both cases. Xenomai send/receive/reply messaging would work,
but here priority inversion might happen, if there is any other with a
priority between the sender with the low priority and the basis priority
of the receiver. 'Common' Synchronous Message Passing would work exactly
the same way. If the receiver thread blocks during the processing of the
first message from the high-priority sender thread, the second
low-priority thread might be scheduled and could send the second
message. But in this second case, the receiver remains in the high
priority until it calls the reply-function. When it then receives the
second message, the receiver inherits the low priority of the second
sender thread. But in this case, priority inversion problems cannot
arise.

Please let me know, if I'm mistaking. I'm not really a specialist in
this field. All I have experienced is that the basic flow chart of
send/receive/reply-messaging looks really simple - but its robust
real-time capable implementation is quite sophisticated.

Actually my aim is to develop 'common' real-time capable Synchronous
Message Passing for the posix skin of Xenomai, but right know my
conclusion is the following: its realization is not possible, except
_all_ threads are part of one and only one process. But this seems
really not to be practical and hence I'm looking for other solutions.
 
Any comments on this are really appreciated again.


Best regards from Braunschweig,
Torsten