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.
Processes and Threads
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.
Starting a thread
Now that we've seen how to start another process, let's see how to start another thread.
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.
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.

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
      - 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 Neutrino, message passing. Message passing lies at the heart of the operating system's microkernel architecture, giving the OS its modularity.
    - 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.

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.

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.
Threads and Interrupt Service Routines (ISRs) also do run concurrently—this means that not only will you have to protect the thread from the ISR, but you'll also have to protect the ISR from the thread. See the Interrupts chapter for more details.
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 12, 2026