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.
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.
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.
The kernel as arbiter
So who decides which thread is going to run at any given instant in time? That's the kernel's job.
The rules
Let's summarize the scheduling rules (for a single CPU), in order of importance.

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.
        Single CPU
        Let's look at what happens in the real world, and specifically, the economy case where we have one CPU in the system. In this case, since there's only one CPU present, only one thread can run at any given point in time. The kernel decides (using a number of rules, which we'll see shortly) which thread to run, and runs it.
        Multiple CPU (SMP)
        If you buy a system that has multiple, identical CPUs all sharing memory and devices, you have an SMP box (SMP stands for Symmetrical Multi Processor, with the symmetrical part indicating that all the CPUs in the system are identical). In this case, the number of threads that can run concurrently (simultaneously) is limited by the number of CPUs. (In reality, this was the case with the single-processor box too!) Since each processor can execute only one thread at a time, with multiple processors, multiple threads can execute simultaneously.
        The kernel as arbiter
        So who decides which thread is going to run at any given instant in time? That's the kernel's job.
        Prioritization
        Consider two threads capable of using the CPU. If these threads have different priorities, then the answer is really quite simple; the kernel gives the CPU to the highest priority thread. QNX OS's priorities go from one (the lowest usable) and up, as we mentioned when we talked about obtaining mutexes. Note that priority zero is reserved for the idle thread—you can't use it.
        Scheduling policies
        Now, suppose that two threads are capable of using the CPU and have the exact same priority. Let's assume that one of the threads is currently using the CPU. We'll examine the rules that the kernel uses to decide when to context-switch in this case.
        FIFO
        In the FIFO scheduling policy, a thread is allowed to consume CPU for as long as it wants. This means that if that thread is doing a very long mathematical calculation, and no other thread of a higher priority is ready, that thread could potentially run forever. What about threads of the same priority? They're locked out as well. (It should be obvious that threads of a lower priority are locked out too.)
        Round Robin (RR)
        The RR scheduling policy is identical to FIFO, except that the thread will not run forever if there's another thread at the same priority. It runs only for a system-defined timeslice whose value you can determine by using the function sched_rr_get_interval(). The timeslice is usually 4 ms, but it's actually 4 times the ticksize, which you can query with ClockPeriod().
        The rules
        Let's summarize the scheduling rules (for a single CPU), in order of importance.
        Kernel states
        We've been talking about running, ready, and blocked loosely—let's now formalize these thread states.
      - 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.
      - 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 software in Amazon Web Services (AWS) and Microsoft Azure (Azure).
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 and QNX Hypervisor for Safety
The QNX Hypervisor and QNX Hypervisor for Safety products allow 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.
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.

The rules

QNX SDP8.0Getting Started with the QNX OSDeveloperUser

Let's summarize the scheduling rules (for a single CPU), in order of importance.

Only one thread can run at a time.
The highest-priority ready thread will run.
A thread will run until it blocks or exits.
An RR thread will run for its timeslice, and then the kernel will reschedule it (if required).

The following flowchart shows the decisions that the kernel makes:

Scheduling roadmap — Figure 1Scheduling roadmap.

For a multiple-CPU (SMP) system, the rules are mostly the same, but multiple CPUs can run multiple threads concurrently. The order in which the threads run (i.e., which threads get to run on the CPUs at certain times) is determined in a similar way as with a single CPU, except that the processor affinity (i.e., the binding of that thread to a specific set of CPUs) is considered in each scheduling decision. Thus, for a given CPU, the highest-priority READY thread whose processor affinity setting (i.e., its runmask) includes that CPU will run on it. For information about runmasks, refer to Processor affinity, clusters, runmasks, and inherit masks in the Programmer's Guide.

For lower-priority or longer-waiting threads, the kernel has some flexibility as to when to schedule them to avoid inefficiency in the use of the cache. For more information about SMP, see the Multicore Processing chapter of the QNX OS Programmer's Guide.

Page updated: March 25, 2026