QNX Community Resources
This chapter covers the following topics:
- Interprocess communication
- IPC via messages
- IPC via proxies
- IPC via signals
- IPC across the network
- IPC via semaphores
- Process scheduling

QNX Community Resources
This chapter covers the following topics:
- Interprocess communication
- IPC via messages
- IPC via proxies
- IPC via signals
- IPC across the network
- IPC via semaphores
- Process scheduling
- A word about realtime performance
The QNX Microkernel is responsible for the following:
- IPC -- the Microkernel supervises the routing of messages; it also manages two other forms of IPC: proxies and signals
- low-level network communication -- the Microkernel delivers all messages destined for processes on other nodes
- process scheduling -- the Microkernel's scheduler decides which process will execute next
- first-level interrupt handling -- all hardware interrupts and faults are first routed through the Microkernel, then passed on to the appropriate driver or system manager
Inside the QNX Microkernel.
The QNX Microkernel supports three essential types of IPC: messages, proxies, and signals.
- Messages -- the fundamental form of IPC in QNX. They provide synchronous communication between cooperating processes where the process sending the message requires proof of receipt and potentially a reply to the message.
- Proxies -- a special form of message. They're especially suited for event notification where the sending process doesn't need to interact with the recipient.
- Signals -- a traditional form of IPC. They're used to support asynchronous interprocess communication.
In QNX, a message is a packet of bytes that's synchronously transmitted from one process to another. QNX attaches no meaning to the content of a message. The data in a message has meaning for the sender and for the recipient, but for no one else.
To communicate directly with one another, cooperating processes use these C language functions:
|Send()||to send messages|
|Receive()||to receive messages|
|Reply()||to reply to processes that have sent messages|
These functions may be used locally or across the network.
Note also that unless processes want to communicate directly with each other, they don't need to use Send(), Receive(), and Reply(). The QNX C Library is built on top of messaging -- processes use messaging indirectly when they use standard services, such as pipes.
Process A sends a message to Process B, which subsequently receives, processes, then replies to the message.
The above illustration outlines a simple sequence of events in which two processes, Process A and Process B, use Send(), Receive(), and Reply() to communicate with each other:
- Process A sends a message to Process B by issuing a Send() request to the Microkernel. At this point, Process A becomes SEND-blocked until Process B issues a Receive() to receive the message.
- Process B issues a Receive() and
receives Process A's waiting message. Process A
changes to a REPLY-blocked state. Since a message was
waiting, Process B doesn't block.
(Note that if Process B had issued the Receive() before a message was sent, it would become RECEIVE-blocked until a message arrived. In this case, the sender would immediately go into the REPLY-blocked state when it sent its message.)
- Process B completes the processing associated with the message it received from Process A and issues a Reply(). The reply message is copied to Process A, which is made ready to run. A Reply() doesn't block, so Process B is also ready to run. Who runs depends on the relative priorities of Process A and Process B.
Message passing not only allows processes to pass data to each other, but also provides a means of synchronizing the execution of several cooperating processes.
Let's look at the above illustration again. Once Process A issues a Send() request, it's unable to resume execution until it has received the reply to the message it sent. This ensures that the processing performed by Process B for Process A is complete before Process A can resume executing. Moreover, once Process B has issued its Receive() request, it can't continue processing until it receives another message.
|For details on how QNX schedules processes, see "Process scheduling" in this chapter.|
When a process isn't allowed to continue executing -- because it must wait for some part of the message protocol to end -- the process is said to be blocked.
The followin