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 the QNX OS 8.0.
Programming
Getting Started with the QNX OS
Getting Started with the QNX OS: A Guide for Realtime Programmers is intended to introduce you to the QNX OS 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 OS, message passing. Message passing lies at the heart of the operating system's microkernel architecture, giving the OS its modularity.
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.
Channel flags
When we introduced the server (in The server), we mentioned that the ChannelCreate() function takes a flags parameter and that we'd just leave it as zero.
_NTO_CHF_UNBLOCK
Let's look at the _NTO_CHF_UNBLOCK flag; it has a few interesting wrinkles for both the client and the server.
Using the _NTO_MI_UNBLOCK_REQ
Luckily, the kernel keeps track of the flag for you as a single bit in the message info structure (the struct _msg_info that you pass as the last parameter to MsgReceive(), or that you can fetch later, given the receive ID, by calling MsgInfo()).

QNX Momentics IDE User's Guide
This User's Guide describes version 8.0 of the Integrated Development Environment (IDE) that's part of the QNX 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 the QNX OS 8.0.
- Quickstart Guide
- System Architecture
  The System Architecture guide accompanies the QNX OS and is intended for both application developers and end-users.
- OS Components & Operations
- Graphics
- Programming
  - Getting Started with the QNX OS
    Getting Started with the QNX OS: A Guide for Realtime Programmers is intended to introduce you to the QNX OS and help you develop applications and resource managers for it.
    - Processes and Threads
      This chapter explains the concepts behind processes and threads, and the challenges of synchronization and scheduling. A thread is a flow of execution, and a process is a collection of threads. In the QNX OS, the schedulable entity is a thread, not a process.
    - Message Passing
      In this chapter, we'll look at the most distinctive feature of QNX OS, 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 OS 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.
      - What it means for you
        Message passing is elegant. 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.
      - 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.
        Receiving a pulse message
        Receiving a pulse is very simple: a tiny, well-defined message is presented to the MsgReceive(), as if a thread had sent a normal message. The only difference is that you can't MsgReply() to this message—after all, the whole idea of a pulse is that it's asynchronous. In this section, we'll take a look at another function, MsgReceivePulse(), that's useful for dealing with pulses.
        The MsgDeliverEvent() function
        As mentioned above in The send-hierarchy, there are cases when you need to break the natural flow of sends.
        Channel flags
        When we introduced the server (in The server), we mentioned that the ChannelCreate() function takes a flags parameter and that we'd just leave it as zero.
        _NTO_CHF_UNBLOCK
        Let's look at the _NTO_CHF_UNBLOCK flag; it has a few interesting wrinkles for both the client and the server.
        Synchronization problem
        Even if you use the _NTO_CHF_UNBLOCK flag, there's still one more synchronization problem to deal with.
        Using the _NTO_MI_UNBLOCK_REQ
        Luckily, the kernel keeps track of the flag for you as a single bit in the message info structure (the struct _msg_info that you pass as the last parameter to MsgReceive(), or that you can fetch later, given the receive ID, by calling MsgInfo()).
      - Priority inversion
        One of the interesting issues in a realtime operating system is a phenomenon known as priority inversion. This can be fixed by a mechanism known as priority inheritance.
    - Interrupts
      In this chapter, we'll take a look at interrupts, how we deal with them under QNX OS, 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 OS 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 OS Programmer's Guide covers a variety of topics that might interest developers who are building applications that will run under the QNX OS.
  - Writing a Resource Manager
- System Security Guide
  The QNX System Security Guide is intended for both system integrators who are responsible for the security of a QNX OS system and developers who want to create a QNX OS resource manager free from vulnerabilities.
- Utilities & Libraries
- Migrating to QNX OS 8.0
QNX Software in the Cloud
QNX Software in the Cloud enables developers to use the QNX OS in the Amazon cloud environment.
QNX Toolkit for Visual Studio Code
This User's Guide describes the QNX^® Toolkit for Visual Studio Code. The guide introduces you to the QNX Toolkit by explaining the QNX development environment and how to build, run, and debug your QNX^® Operating System (OS) applications and systems.
QNX Hypervisor User's Guide
This User's Guide explains the QNX hypervisor architecture and provides instructions for installing and running a QNX Hypervisor system, changing system components and configuration, and using hypervisor features such as virtual devices (vdevs).
Typographical Conventions, Support, and Licensing
This section describes the typographical conventions used throughout the documentation, explains how to obtain technical support, and provides some information about licensing.

Using the _NTO_MI_UNBLOCK_REQ

QNX SDP8.0Getting Started with the QNX OSDeveloperUser

Luckily, the kernel keeps track of the flag for you as a single bit in the message info structure (the struct _msg_info that you pass as the last parameter to MsgReceive(), or that you can fetch later, given the receive ID, by calling MsgInfo()).

This flag is called _NTO_MI_UNBLOCK_REQ and is set if the client wishes to unblock (for example, after receiving a signal).

This means that in a multithreaded server, you'd typically have a worker thread that's performing the client's work, and another thread that's going to receive the unblock message (or some other message; we'll just focus on the unblock message for now). When you get the unblock message from the client, you'd set a flag to yourself, letting your program know that the worker thread wishes to unblock.

There are two cases to consider:

the worker thread is blocked; or
the worker thread is running.

If the worker thread is blocked, you'll need to have the thread that got the unblock message awaken it. It might be blocked if it's waiting for a resource, for example. When the worker thread wakes up, it should examine the _NTO_MI_UNBLOCK_REQ flag, and, if set, reply with an abort status. If the flag isn't set, then the thread can do whatever normal processing it does when it wakes up.

Alternatively, if the worker thread is running, it should periodically check the flag to self that the unblock thread may have set, and if the flag is set, it should reply to the client with an abort status. Note that this is just an optimization: in the unoptimized case, the worker thread would constantly call MsgInfo on the receive ID and check the _NTO_MI_UNBLOCK_REQ bit itself.

Page updated: March 05, 2025