Getting Started with QNX Neutrino - QNX Software Systems

Message passing and client/server
© 2009, QNX Software Systems GmbH & Co. KG.
The key to accomplishing this is message passing. Instead of having the OS modules
bound directly into the kernel, and having some kind of “special” arrangement with
the kernel, under Neutrino the modules communicate via message passing among
themselves. The kernel is basically responsible only for thread-level services (e.g.,
scheduling). In fact, message passing isn’t used just for this installation and
deinstallation trick — it’s the fundamental building block for almost all other services
(for example, memory allocation is performed by a message to the process manager).
Of course, some services are provided by direct kernel calls.
Consider opening a file and writing a block of data to it. This is accomplished by a
number of messages sent from the application to an installable component of Neutrino
called the filesystem. The message tells the filesystem to open a file, and then another
message tells it to write some data (and contains that data). Don’t worry though — the
Neutrino operating system performs message passing very quickly.
Message passing and client/server
Imagine an application reading data from the filesystem. In QNX lingo, the
application is a client requesting the data from a server.
This client/server model introduces several process states associated with message
passing (we talked about these in the Processes and Threads chapter). Initially, the
server is waiting for a message to arrive from somewhere. At this point, the server is
said to be receive-blocked (also known as the RECV state). Here’s some sample pidin
output:
pid tid name prio STATE Blocked
4 1 devc-pty 10r RECEIVE 1
In the above sample, the pseudo-tty server (called devc-pty) is process ID 4, has one
thread (thread ID 1), is running at priority 10 Round-Robin, and is receive-blocked,
waiting for a message from channel ID 1 (we’ll see all about “channels” shortly).
READY
RECEIVE
State transitions of server.
When a message is received, the server goes into the READY state, and is capable of
running. If it happens to be the highest-priority READY process, it gets the CPU and
can perform some processing. Since it’s a server, it looks at the message it just got and
decides what to do about it. At some point, the server will complete whatever job the
message told it to do, and then will “reply” to the client.
Let’s switch over to the client. Initially the client was running along, consuming CPU,
until it decided to send a message. The client changed from READY to either
send-blocked or reply-blocked, depending on the state of the server that it sent a
message to.
82 Chapter 2 • Message Passing April 30, 2009