Hi all
I suppose that QNX (both 4 and 6) propagate the concept of priority
above the net when IPC between two (or more) boxes uses Qnet.
Little example:
process A runs on node FOO, prio 10, receive-blocked.
process B runs on node FOO, prio 15, READY.
process C runs on node BAR, prio 20, it makes a MsgSend() to A
(or a Send() on qnx4)
I think that B will be preempted by A, because C is pending send-blocked
on A, boosting its prio to (at least) 20.
But what about when both B and C priorities are higher than the priority
of io-net threads handling network traffic (or Net and Net.ether*** for
qnx4)?
I suppose priority propagation cannot be guaranteed (and it seems to be
unavoidable, also than acceptable…). Am I right?
Davide
–
/* Ancri Davide - */
As I understand it…
If B is running READY and it is a higher priority than io-net, io-net
will not run.
Suppose io-net was running at priority 18. It would receive the qnet
message and pass it on to A. Assuming you haven’t suppressed priority
inheritance on the channel, A’s priority would be bumped up to the
sender’s (C) priority. A would be preempt B and io-net. When A was
finished it would Reply(), blocking, and io-net would get to run to send
the message back. While A was running READY, io-net would not run.
–
Ryan J. Allen
ryallen@qnx.com
Davide Ancri wrote:
Hi all
I suppose that QNX (both 4 and 6) propagate the concept of priority
above the net when IPC between two (or more) boxes uses Qnet.
Little example:
process A runs on node FOO, prio 10, receive-blocked.
process B runs on node FOO, prio 15, READY.
process C runs on node BAR, prio 20, it makes a MsgSend() to A
(or a Send() on qnx4)
I think that B will be preempted by A, because C is pending send-blocked
on A, boosting its prio to (at least) 20.
But what about when both B and C priorities are higher than the priority
of io-net threads handling network traffic (or Net and Net.ether*** for
qnx4)?
I suppose priority propagation cannot be guaranteed (and it seems to be
unavoidable, also than acceptable…). Am I right?
Davide
Ryan J. Allen wrote:
As I understand it…
If B is running READY and it is a higher priority than io-net, io-net
will not run.
Suppose io-net was running at priority 18. It would receive the qnet
message and pass it on to A. Assuming you haven’t suppressed
priority inheritance on the channel, A’s priority would be bumped up
to the sender’s (C) priority. A would be preempt B and io-net. When
A was finished it would Reply(), blocking, and io-net would get to
run to send the message back. While A was running READY, io-net
would not run.
Ok, it’s like I was expecting.
It’s nice to feel something sure under my feet 
Only another question: what do you mean for “it would Reply(), blocking,
and io-net would get to run to send the message back”?
I suppose that when a thread issues MsgReply(), the microkernel copy the
data buffer into the io-net space immediatly, then io-net is scheduled
to setup the ethernet driver for sending the message(s), leaving the
replying thread free to run as soon as the CPU is given to its priority
level.
Am I right?
Thanks for your answer!
Davide
–
/* Ancri Davide - */
Davide Ancri wrote:
Only another question: what do you mean for “it would Reply(), blocking,
and io-net would get to run to send the message back”?
Well, I was being a bit presumptuous. With a local message Process A
would MsgReply() and continue to run as per its scheduling. Typically
after MsgReply() a process will quickly loop back to it’s MsgReceive()
where it may block. With a network message, the actual MsgReply()
function may block so that some network stuff can happen. I suspect
io-net would run long enough to send the reply back to C but it may just
run long enough to do some setup.
I suppose that when a thread issues MsgReply(), the microkernel copy the
data buffer into the io-net space immediatly, then io-net is scheduled
to setup the ethernet driver for sending the message(s), leaving the
replying thread free to run as soon as the CPU is given to its priority
level.
Am I right?
Yes, it looks like you have a good understanding.
–
Ryan J. Allen
ryallen@qnx.com