Home
QNX Software Development Platform
QNX SDP is a cross-compiling and debugging environment, including an IDE and command-line tools, for building binary images and programs for target boards running QNX Neutrino 7.1.
Programming
Getting Started with QNX Neutrino
Getting Started with QNX Neutrino: A Guide for Realtime Programmers is intended to introduce you to the QNX Neutrino RTOS and help you develop applications and resource managers for it.
Message Passing
In this chapter, we'll look at the most distinctive feature of QNX Neutrino, message passing. Message passing lies at the heart of the operating system's microkernel architecture, giving the OS its modularity.
Using message passing
Now that we've seen the basic concepts involved in message passing, and learned that even common everyday things like the C library use it, let's take a look at some of the details.
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.
The receive ID (a.k.a. the client cookie)
In the code sample above, notice how we stored the receive ID.

QNX Momentics IDE User's Guide
This User's Guide describes version 7.1 of the Integrated Development Environment (IDE) that's part of the QNX Momentics tool suite.
QNX Software Development Platform
QNX SDP is a cross-compiling and debugging environment, including an IDE and command-line tools, for building binary images and programs for target boards running QNX Neutrino 7.1.
- Quickstart Guide
- OS Components & Operations
- Audio & Graphics API
- Multimedia
- Networking Middleware
- Programming
  - Getting Started with QNX Neutrino
    Getting Started with QNX Neutrino: A Guide for Realtime Programmers is intended to introduce you to the QNX Neutrino RTOS and help you develop applications and resource managers for it.
    - Processes and Threads
    - Message Passing
      In this chapter, we'll look at the most distinctive feature of QNX Neutrino, message passing. Message passing lies at the heart of the operating system's microkernel architecture, giving the OS its modularity.
      - A small microkernel and message passing
        One of the principal advantages of QNX Neutrino is that it's scalable. By scalable I mean that it can be tailored to work on tiny embedded boxes with tight memory constraints, right up to large networks of multiprocessor SMP boxes with almost unlimited memory.
      - 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.
      - Network-distributed message passing
        Suppose we want to change our example above to talk to a different node on the network. You might think that we'll have to invoke special function calls to get networked.
      - What it means for you
        Message passing is elegant and network-distributed. So what? What does it buy you, the programmer?
      - Multiple threads
        Although the client/server model is easy to understand, and the most commonly used, there are two other variations on the theme. The first is the use of multiple threads (the topic of this section), and the second is a model called server/subserver that's sometimes useful for general design, but really shines in network-distributed designs. The combination of the two can be extremely powerful, especially on a network of SMP boxes!
      - Using message passing
        Now that we've seen the basic concepts involved in message passing, and learned that even common everyday things like the C library use it, let's take a look at some of the details.
        Architecture & structure
        We've been talking about clients and servers. I've also used three key phrases.
        The client
        The client wants to send a request to a server, block until the server has completed the request, and then when the request is completed and the client is unblocked, to get at the answer.
        The server
        Now that we've seen the client, let's look at the server. The client used ConnectAttach() to create a connection to a server, and then used MsgSend() for all its message passing.
        Identifying messages
        While the message-passing APIs transfer buffers of bytes without caring about the content, the client and server almost always care.
        The send-hierarchy
        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 lower level, never to the same or higher level.
        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.
        More about channels
        In the server example above, we saw that the server created just one channel. It could certainly have created more, but generally, servers don't do that. (The most obvious example of a server with two channels is the Transparent Distributed Processing (TDP, also known as Qnet) native network manager—definitely an odd piece of software!)
        Who sent the message?
        Often a server will need to know who sent it a message. There are a number of reasons for this.
        The receive ID (a.k.a. the client cookie)
        In the code sample above, notice how we stored the receive ID.
        Replying to the client
        MsgReply() accepts a receive ID, a status, a message pointer, and a message size. We've just finished discussing the receive ID; it identifies who the reply message should be sent to. The status variable indicates the return status that should be passed to the client's MsgSend() function. Finally, the message pointer and size indicate the location and size of the optional reply message that should be sent.
        Not replying to the client
        There's absolutely no requirement that you reply to a client before accepting new messages from other clients via MsgReceive()! This can be used in a number of different scenarios.
        Replying with no data, or an errno
        When you finally reply to the client, there's no requirement that you transfer any data. This is used in two scenarios.
        Finding the server's ND/PID/CHID
        You've noticed that in the ConnectAttach() function, we require a Node Descriptor (ND), a process ID (PID), and a channel ID (CHID) in order to be able to attach to a server. So far we haven't talked about how the client finds this ND/PID/CHID information.
        What about priorities?
        What if a low-priority process and a high-priority process send a message to a server at the same time?
        Reading and writing data
        So far you've seen the basic message-passing primitives. As I mentioned earlier, these are all that you need. However, there are a few extra functions that make life much easier.
        Multipart messages
        Until now, we've shown only message transfers happening from one buffer in the client's address space into another buffer in the server's address space. (And one buffer in the server's space into another buffer in the client's space during the reply.)
      - Pulses
        All the messaging we've talked about so far blocks the client. It's nap time for the client as soon as it calls MsgSend(). The client sleeps until the server gets around to replying.
      - Message passing over a network
        To keep things clear, I've avoided talking about how you'd use message passing over a network, even though this is a crucial part of QNX Neutrino's flexibility!
      - Priority inheritance
        One of the interesting issues in a realtime operating system is a phenomenon known as priority inversion.
    - Clocks, Timers, and Getting a Kick Every So Often
      It's time to take a look at everything related to time in the QNX Neutrino RTOS. We'll see how and why you'd use timers and the theory behind them. Then we'll take a look at getting and setting the realtime clock.
    - Interrupts
      In this chapter, we'll take a look at interrupts, how we deal with them under QNX Neutrino, their impact on scheduling and realtime, and some interrupt-management strategies.
    - Resource Managers
      In this chapter, we'll take a look at what you need to understand in order to write a resource manager. Resource managers are another distintive feature of QNX Neutrino that allow you to access services through standard POSIX calls.
    - Sample Programs
      This appendix contains the complete versions of some of the sample programs discussed in this book.
    - Glossary
  - Programmer's Guide
    The QNX Neutrino Programmer's Guide covers a variety of topics that might interest developers who are building applications that will run under the QNX Neutrino RTOS.
  - The QNX Neutrino Cookbook: Recipes for Programmers
  - Writing a Resource Manager
- Sensor Framework
- System Security Guide
  The QNX System Security Guide is intended for both system integrators who are responsible for the security of a QNX Neutrino RTOS system and developers who want to create a QNX Neutrino resource manager free from vulnerabilities.
- Utilities & Libraries
QNX Hypervisor
The QNX Hypervisor allows you to run multiple OSs on a target system so you can separate critical and non-critical functions, support a wide variety of applications, and reduce hardware costs.
QNX Software in the Cloud
QNX Software in the Cloud enables developers to use the QNX software in Amazon Web Services (AWS) and Microsoft Azure (Azure).
QNX Advanced Virtualization Frameworks User's Guide
This User's Guide is aimed at all systems integrators and developers who want to design and build embedded systems using the QNX Advanced Virtualization Frameworks.
Typographical Conventions, Support, and Licensing
This section describes the typographical conventions used throughout the documentation and explains how to obtain technical support.

The receive ID (a.k.a. the client cookie)

In the code sample above, notice how we stored the receive ID.

rcvid = MsgReceive (...);
...
MsgReply (rcvid, ...);

This is a key snippet of code, because it illustrates the binding between receiving a message from a client, and then being able to (sometime later) reply to that particular client. The receive ID is an integer that acts as a magic cookie that you'll need to hold onto if you want to interact with the client later. What if you lose it? It's gone. The client will not unblock from the MsgSend() until you (the server) die, or if the client has a timeout on the message-passing call (and even then it's tricky; see the TimerTimeout() function in the QNX Neutrino C Library Reference, and the discussion about its use in the Clocks, Timers, and Getting A Kick Every So Often chapter, under Kernel timeouts).

Note:

Don't depend on the value of the receive ID to have any particular meaning—it may change in future versions of the operating system. You can assume that it will be unique, in that you'll never have two outstanding clients identified by the same receive IDs (in that case, the kernel couldn't tell them apart either when you do the MsgReply()).

Also, note that except in one special case (the MsgDeliverEvent() function which we'll look at later), once you've done the MsgReply(), that particular receive ID ceases to have meaning.

This brings us to the MsgReply() function.

Page updated: March 12, 2026