Getting Started with QNX Neutrino - QNX Software Systems

© 2009, QNX Software Systems GmbH & Co. KG. Using message passing
The kernel transfers the minimum specified by both sizes. In our case, the kernel
would transfer 28 bytes. The server would be unblocked and print out the client’s
message. The remaining 484 bytes (of the 512 byte buffer) will remain unaffected.
We run into the same situation again with MsgReply(). The MsgReply() function says
that it wants to transfer 512 bytes, but our client’s MsgSend() function has specified
that a maximum of 200 bytes can be transferred. So the kernel once again transfers the
minimum. In this case, the 200 bytes that the client can accept limits the transfer size.
(One interesting aspect here is that once the server transfers the data, if the client
doesn’t receive all of it, as in our example, there’s no way to get the data back — it’s
gone forever.)
The send-hierarchy
Keep in mind that this “trimming” operation is normal and expected behavior.
When we discuss message passing over a network, you’ll see that there’s a tiny
“gotcha” with the amount of data transferred. We’ll see this in “Networked
message-passing differences,” below.
One thing that’s perhaps not obvious in a message-passing environment is the need to
follow a strict send-hierarchy. What this means is that two threads should never send
messages to each other; rather, they should be organized such that each thread
occupies a “level”; all sends go from one level to a higher level, never to the same or
lower level. The problem with having two threads send messages to each other is that
eventually you’ll run into the problem of deadlock — both threads are waiting for each
other to reply to their respective messages. Since the threads are blocked, they’ll never
get a chance to run and perform the reply, so you end up with two (or more!) hung
threads.
The way to assign the levels to the threads is to put the outermost clients at the highest
level, and work down from there. For example, if you have a graphical user interface
that relies on some database server, and the database server in turn relies on the
filesystem, and the filesystem in turn relies on a block filesystem driver, then you’ve
got a natural hierarchy of different processes. The sends will flow from the outermost
client (the graphical user interface) down to the lower servers; the replies will flow in
the opposite direction.
While this certainly works in the majority of cases, you will encounter situations
where you need to “break” the send hierarchy. This is never done by simply violating
the send hierarchy and sending a message “against the flow,” but rather by using the
MsgDeliverEvent() function, which we’ll take a look at later.
Receive IDs, channels, and other parameters
We haven’t talked about the various parameters in the examples above so that we
could focus just on the message passing. Now let’s take a look.
April 30, 2009 Chapter 2 • Message Passing 97