sched_setscheduler() question

I have a parent process that spawns several children with spawnl(). I then
change the priority of the children and parent from the parent using:

struct sched_param param;

param.sched_priority = 23;
sched_setscheduler( 0, SCHED_FIFO, &param );
param.sched_priority = 22;
sched_setscheduler( pidA, SCHED_FIFO, &param );
param.sched_priority = 24;
sched_setscheduler( pidB, SCHED_FIFO, &param );

This works fine and I can see using pidin that the processes have the
correct priorities. However when any process communication takes place
between the parent and the children (ie MsgSend() ), the priority of the
children is changed to that of the parent ie 23 in this case, and their
priorities stay at 23 even after the IPC is finished.

Why does this priority change occur? Is there any way to prevent it?

That happens due to ‘priority inheritance’ protocol, which is intentded to
solve ‘priority inversion’ problem. I am not sure why priority does not go
back to original value when IPC transaction is completed, I think it should,
if you’re talking about messages. In case of pulses that is normal, because
there’s no reply so there’s no way to tell if transaction is completed.

This behavior can be disabled by setting some flag on the channel
(_NTO_FIXED_PRIORITY or such), see ChannelCreate() docs.

  • igor

“Paul Jones” <paul.jones@bnc.ox.ac.uk> wrote in message
news:9s0sr7$sii$1@inn.qnx.com

I have a parent process that spawns several children with spawnl(). I
then
change the priority of the children and parent from the parent using:

struct sched_param param;

param.sched_priority = 23;
sched_setscheduler( 0, SCHED_FIFO, &param );
param.sched_priority = 22;
sched_setscheduler( pidA, SCHED_FIFO, &param );
param.sched_priority = 24;
sched_setscheduler( pidB, SCHED_FIFO, &param );

This works fine and I can see using pidin that the processes have the
correct priorities. However when any process communication takes place
between the parent and the children (ie MsgSend() ), the priority of the
children is changed to that of the parent ie 23 in this case, and their
priorities stay at 23 even after the IPC is finished.

Why does this priority change occur? Is there any way to prevent it?

If a server process is honoring requests from many clients, the OS has no
way of knowing what priority to adjust a process to after replyiny to a
message.

What the server process should do is always be aware of what priority it is
currently running at and requery that priority after receiving a message.
Then, after completing the request for that client, it itself can dedtermine
whuch client it will begin to serve next and adjust it’w own priority to
that process.

Ok, so as the keystrokes left my fingers I can already poke wholes in that
plan. I.E. if

  1. a server replies to a client
  2. a new high priority client sends a request
  3. the server adjusts it’s priority down to some lower number
    THEN, the server will be running at too low a priority.

I’m not sure what the correct method of reducing you priority is after
servicing a client when there IS more work for it to do. Usually, after
replying to a client a server will wait to receive a new message which will
also adjust its own priority. But I’m seeing servers concurrently
processing multiple clients more and more often.

Maybe some kernel guru can help out here.


Bill Caroselli – 1(530) 510-7292
Q-TPS Consulting
QTPS@EarthLink.net


“Igor Kovalenko” <kovalenko@home.com> wrote in message
news:9s1g6h$a1m$1@inn.qnx.com

That happens due to ‘priority inheritance’ protocol, which is intentded to
solve ‘priority inversion’ problem. I am not sure why priority does not go
back to original value when IPC transaction is completed, I think it
should,
if you’re talking about messages. In case of pulses that is normal,
because
there’s no reply so there’s no way to tell if transaction is completed.

This behavior can be disabled by setting some flag on the channel
(_NTO_FIXED_PRIORITY or such), see ChannelCreate() docs.

  • igor

“Paul Jones” <> paul.jones@bnc.ox.ac.uk> > wrote in message
news:9s0sr7$sii$> 1@inn.qnx.com> …
I have a parent process that spawns several children with spawnl(). I
then
change the priority of the children and parent from the parent using:

struct sched_param param;

param.sched_priority = 23;
sched_setscheduler( 0, SCHED_FIFO, &param );
param.sched_priority = 22;
sched_setscheduler( pidA, SCHED_FIFO, &param );
param.sched_priority = 24;
sched_setscheduler( pidB, SCHED_FIFO, &param );

This works fine and I can see using pidin that the processes have the
correct priorities. However when any process communication takes place
between the parent and the children (ie MsgSend() ), the priority of the
children is changed to that of the parent ie 23 in this case, and their
priorities stay at 23 even after the IPC is finished.

Why does this priority change occur? Is there any way to prevent it?
\

I still don’t understand why it works this way. Surely priority inversion
is only a problem while a high priority process is reply blocked after
sending a message to a low priority process. Therefore the priority
inheritance should only last until the reply has been received. In the case
of pulses there is no blocking so priority inversion can not occur, so
priority inheritance is not required.

Am I missing something here?

Paul.

“Paul Jones” <paul.jones@bnc.ox.ac.uk> wrote in message
news:9s64d7$9ql$1@inn.qnx.com

I still don’t understand why it works this way. Surely priority inversion
is only a problem while a high priority process is reply blocked after
sending a message to a low priority process. Therefore the priority
inheritance should only last until the reply has been received. In the
case
of pulses there is no blocking so priority inversion can not occur, so
priority inheritance is not required.

Priority inversion can happen when a low priority thread holds/locks a
resource, and is then scheduled out b/c a higher priority thread became
ready. If that high priority thread requires the resource/lock that is held
by the low priority thread, it’s stuck until the low priority thread
releases that lock (which it can’t until the high priority thread blocks).

-Adam