IPC via messages

In QNX a message is a packet of bytes that is synchronously transmitted from one process to another. QNX attaches no meaning to content of a message. To communicate directly with one another, cooperating processes use these C language functions:

• Send() for sending messages,
• Receive() for receiving messages, and
• Reply() for replying to process that have sent messages.

These functions can be used locally or across the network.

Next picture illustrates 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:

1. Process A sends a message to Process B by issuing a Send() request to the Kernel. At this point, Process A becomes SEND-blocked until Process B issues a Receive() to receive the message.
2. Prtocess B issues a Receive() and receives Process A's waiting message. Process A changes to a REPLY-blocked state. Since a massege was waiting, Process B does not block.
   If Process B has 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.
3. Propcess 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 runs depends on the relative priorities of Process A and Process B.

Blocked states

When a process is not 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 following table summarizes the blocked states of processes:

If a process has issued a:	the process is:
Send() request, and the message it has sent has not yet received by the recipient process	SEND-blocked
Send() request, and the message has been received by the recipient process, but that process has not yet replied	REPLY-blocked
Receive() request, but has not yet received a message	RECEIVE-blocked

Advanced facilities

The QNX provides these advanced massage-passing facilities:

• Conditional message reception

If a process need determine whether messages are pending without becoming RECEIVE-blocked, the process could use the Creceive() function to read a message, if one became available, yet return immediately if no further messages were pending.

---

Creceive() should be avoided if it is possible, because it allows to consume the processor continuously at its priority level.

---

• Reading or writing part of a message

Sometimes it is desirable to read or write only a part of a message at a time so that you can use the buffer space already allocated for the message instead of allocating a separate work buffer. It can be done by using Readmsg() and Writemsg() C-functions.

• Multi-part messages

A message may have a fixed length header followd by a variable amount of data. So that it components will be efficiently sent or received without being copied into a temporary work buffer, a multi-part message can be constructed from two or more separate message buffers. This facility helps QNX I/O managers, such as Dev and Fsys, achive their high performance. The following functions are avaliable to handle multi-part messages:

• Creceivemx()
• Readmsgmx()
• Receivemx()
• Sendmx()
• Writemsgmx()

Multi-part messages can be specified with az mx control structure. The kernel assembles these into a single data stream:

Reserved message codes

Quantum begins all of its messages with a 16-bit word called message code. Note that Quantum's system processes use message codes in the following ranges: