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.
      - Process and thread fundamentals
        Before we start talking about threads, processes, time slices, and all the other wonderful scheduling concepts, let's establish an analogy.
      - The kernel's role
        The house analogy is excellent for getting across the concept of synchronization, but it falls down in one major area. In our house, we had many threads running simultaneously. However in a single-processor system, only one thing can run at once.
      - Threads and processes
        Let's return to our discussion of threads and processes, this time from the perspective of a real live system. Then, we'll take a look at the function calls used to deal with threads and processes.
        Why processes?
        So why not just have one process with a zillion threads?
        Starting a process
        Let's now turn our attention to the function calls available to deal with threads and processes. Any thread can start a process; the only restrictions imposed are those that stem from basic security (file access, privilege restrictions, etc.). In all probability, you've already started other processes; either from the system startup script, the shell, or by having a program start another program on your behalf.
        Starting a thread
        Now that we've seen how to start another process, let's see how to start another thread.
        The thread attributes structure
        When you start a new thread, it can assume some well-defined defaults, or you can explicitly specify its characteristics.
        A few examples
        Let's take a look at some examples. We'll assume that the proper include files (<pthread.h> and <sched.h>) have been included, and that the thread to be created is called new_thread() and is correctly prototyped and defined.
        Where a thread is a good idea
        There are two classes of problems where the application of threads is a good idea.
        Threads in mathematical operations
        Suppose that we have a graphics program that performs ray tracing. Each raster line on the screen is dependent on the main database (which describes the actual picture being generated). The key here is this: each raster line is independent of the others. This immediately causes the problem to stand out as a threadable program.
        Coding for SMP or single processor
        The best part about this code is that it will function just fine on a single-processor system—you'll create only one thread, and have it do all the work. The additional overhead (one stack) is well worth the flexibility of having the software just work faster on an SMP box.
        Synchronizing to the termination of a thread
        I mentioned that there were a number of problems with the simplistic code sample initially shown. Another problem with it is that main() starts up a bunch of threads and then displays the results. How does the function know when it's safe to display the results?
        Joining
        The simplest method of synchronization is to join the threads as they terminate. Joining really means waiting for termination.
        Using a barrier
        When we talked about the synchronization of the main() function to the completion of the worker threads (in Synchronizing to the termination of a thread, above), we mentioned two methods: pthread_join(), which we've looked at, and a barrier.
        Multiple threads on a single CPU
        Suppose that we modify our example slightly so that we can illustrate why it's also sometimes a good idea to have multiple threads even on a single-CPU system.
        Things to watch out for when using SMP
        While in general you can simply ignore whether or not you're running on an SMP architecture or a single processor, there are certain things that will bite you. Unfortunately, they may be such low-probability events that they won't show up during development but rather during testing, demos, or the worst: out in the field. Taking a few moments now to program defensively will save problems down the road.
        Threads in independent situations
        As discussed above in the Where a thread is a good idea section, threads also find use where a number of independent processing algorithms are occurring with shared data structures. While strictly speaking you could have a number of processes (each with one thread) explicitly sharing data, in some cases it's far more convenient to have a number of threads in one process instead. Let's see why and where you'd use threads in this case.
      - More on synchronization
      - Scheduling and the real world
        So far we've talked about scheduling policies and thread states, but we haven't said much yet about why and when things are rescheduled.
    - 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.
    - 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.

Things to watch out for when using SMP

QNX SDP8.0Getting Started with the QNX OSDeveloperUser

While in general you can simply ignore whether or not you're running on an SMP architecture or a single processor, there are certain things that will bite you. Unfortunately, they may be such low-probability events that they won't show up during development but rather during testing, demos, or the worst: out in the field. Taking a few moments now to program defensively will save problems down the road.

Here are the kinds of things that you're going to run up against on an SMP system:

Threads really can and do run concurrently—relying on things like FIFO scheduling or prioritization for synchronization is a no-no.
Some operations that you'd expect to be atomic aren't, depending on the operation and processor. Notable operations in this list are things that do a read-modify-write cycle (e.g., ++, --, |=, &= etc.). See the include file <atomic.h> for replacements. (Note that this isn't purely an SMP issue; most RISC processors don't necessarily perform the above code in an atomic manner.)

Page updated: March 05, 2025