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
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
Ok, so as the keystrokes left my fingers I can already poke wholes in that
plan. I.E. if
- a server replies to a client
- a new high priority client sends a request
- 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
“Igor Kovalenko” <firstname.lastname@example.org> wrote in message
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
if you’re talking about messages. In case of pulses that is normal,
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.
“Paul Jones” <> email@example.com> > wrote in message
news:9s0sr7$sii$> firstname.lastname@example.org> …
I have a parent process that spawns several children with spawnl(). I
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, ¶m );
param.sched_priority = 22;
sched_setscheduler( pidA, SCHED_FIFO, ¶m );
param.sched_priority = 24;
sched_setscheduler( pidB, SCHED_FIFO, ¶m );
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?