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.
System Architecture
The System Architecture guide accompanies the QNX OS and is intended for both application developers and end-users.
The QNX OS Microkernel
The microkernel implements the core POSIX features used in embedded realtime systems, along with the fundamental QNX OS message-passing services.
Synchronization services
The QNX OS provides the POSIX-standard thread-level synchronization primitives, all of which can be used between threads in different processes.
Sharing synchronization objects between processes
You can share synchronization objects between threads in different processes, but most objects require extra configuration to work across processes.

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.
  - The Philosophy of the QNX OS
    The primary goal of the QNX OS is to deliver the open systems POSIX API in a robust, scalable form suitable for a wide range of systems—from tiny, resource-constrained embedded systems to high-end distributed computing environments. The OS supports several processor families, including x86 and ARM.
  - The QNX OS Microkernel
    The microkernel implements the core POSIX features used in embedded realtime systems, along with the fundamental QNX OS message-passing services.
    - Design goals of the QNX OS
      Historically, the application pressure on QNX's operating systems has been from both ends of the computing spectrum—from memory-limited embedded systems all the way up to high-end SMP (symmetrical multiprocessing) machines with gigabytes of physical memory.
    - System services
    - Threads and processes
      When building an application (realtime, embedded, graphical, or otherwise), the developer may want several algorithms within the application to execute concurrently. This concurrency is achieved by using the POSIX thread model, which defines a process as containing one or more threads of execution.
    - Thread scheduling
      When and how are scheduling decisions made?
    - Synchronization services
      The QNX OS provides the POSIX-standard thread-level synchronization primitives, all of which can be used between threads in different processes.
      - Mutexes: mutual exclusion locks
        Mutual exclusion locks, or mutexes, are the simplest of the synchronization services. A mutex is used to ensure exclusive access to data shared between threads.
      - Condvars: condition variables
        A condition variable, or condvar, is used to block a thread within a critical section until some condition is satisfied. The condition can be arbitrarily complex and is independent of the condvar. However, the condvar must always be used with a mutex lock in order to implement a monitor.
      - Barriers
        A barrier is a synchronization mechanism that lets you corral several cooperating threads (e.g., in a matrix computation), forcing them to wait at a specific point until all have finished before any one thread can continue.
      - Reader/writer locks
        More formally known as Multiple readers, single writer locks, these locks are used when the access pattern for a data structure consists of many threads reading the data and (at most) one thread writing the data at a particular point in time. Although these locks do not support any form of priority inheritance or priority inversion avoidance, they are useful for this data access pattern.
      - Semaphores
        Semaphores are a common form of synchronization that allows threads to post and wait on a semaphore to control when threads wake or sleep.
      - Sharing synchronization objects between processes
        You can share synchronization objects between threads in different processes, but most objects require extra configuration to work across processes.
      - Synchronization via message passing
        Our Send/Receive/Reply message-passing IPC services implement an implicit synchronization by their blocking nature. These IPC services can, in many instances, render other synchronization services unnecessary.
      - Synchronization via atomic operations
        In some cases, you may want to perform a short operation (such as incrementing a variable) with the guarantee that the operation will perform atomically—that is, the operation won't be preempted by another thread or parallel execution on different cores in SMP.
      - Synchronization services implementation
    - Clock and timer services
      Clock services are used to maintain the time of day, which is in turn used by the kernel timer calls to implement interval timers.
    - Interrupt handling
      No matter how much we wish it were so, computers are not infinitely fast. In a realtime system, it's absolutely crucial that CPU cycles aren't unnecessarily spent. But, it is important to balance this with safety, predictable behaviour, and an avoidance of run-time allocation or queueing. QNX OS implements a low-latency path to schedule user threads to handle hardware interrupts.
    - CPU offlining
      The CPU offlining feature allows a privileged application to stop procnto from using a CPU for scheduling threads.
    - Errata kernel module
      The errata kernel module allows you to choose hardware-specific mitigations to apply to your system, rather than having to apply all mitigations at once, which is inefficient and can affect runtime performance.
  - Interprocess Communication (IPC)
    Interprocess Communication (IPC) plays a fundamental role in the transformation of the microkernel from an embedded realtime kernel into a full-scale POSIX operating system. As various service-providing processes are added to the microkernel, IPC is the glue that connects those components into a cohesive whole.
  - The Microkernel Instrumentation
    The microkernel (procnto-smp-instr) is equipped with a sophisticated tracing and profiling mechanism that lets you monitor your system's execution in real time. This instrumentation works on both single-CPU and SMP systems.
  - Process Manager
    The Process Manager can create and manage multiple POSIX processes, each of which may contain multiple POSIX threads.
  - Dynamic Linking
    In a typical system, a number of programs will be running. Each program relies on a number of functions, some of which will be standard C library functions, like printf(), malloc(), write(), etc.
  - Resource Managers
    To give the QNX OS a great degree of flexibility, to minimize the runtime memory requirements of the final system, and to cope with the wide variety of devices that may be found in a custom embedded system, the OS allows user-written processes to act as resource managers that can be started and stopped dynamically.
  - Filesystems
    The QNX OS provides a rich variety of filesystems. Like most service-providing processes in the OS, these filesystems execute outside the kernel; applications use them by communicating via messages generated by the shared-library implementation of the POSIX API.
  - Character I/O
    A key requirement of any realtime operating system is high-performance character I/O.
  - Networking Architecture
    As with other service-providing processes in the QNX OS, the networking services execute outside the kernel. Developers are presented with a single unified interface, regardless of the configuration and number of networks involved.
  - TCP/IP Networking
    Our TCP/IP stack is included in the io-sock networking stack and uses the common FreeBSD API.
  - High Availability
    The term High Availability (HA) is commonly used in telecommunications and other industries to describe a system's ability to remain up and running without interruption for extended periods of time.
  - What is Real Time and Why Do I Need It?
    Real time is an often misunderstood—and misapplied—property of operating systems. This appendix provides a summary of some of the critical elements of realtime computing and discusses a few design considerations and benefits.
  - Glossary
- OS Components & Operations
- Graphics
- Programming
- 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.

Sharing synchronization objects between processes

QNX SDP8.0System ArchitectureDeveloperUser

You can share synchronization objects between threads in different processes, but most objects require extra configuration to work across processes.

The exception is named semaphores (i.e., those created with sem_open()), which are inherently shared between processes by existing in the pathname space. For the other synchronization primitives, the object must exist in memory that is visible to all processes that want to use the object. Usually this means shared memory; for more information, refer to shm_open()).

Unnamed semaphores must be initialized with the pshared (second) parameter in sem_init() set to a non-zero value; for example:

sem_init(&semaphore_in_shared_memory, 1, 0);

Mutexes, condvars, reader/writer locks, and barriers must be initialized using an attribute structure with the PTHREAD_PROCESS_SHARED flag set; for example, for a mutex:

pthread_mutexattr_t mtx_attr;
pthread_mutexattr_init(&mtx_attr);
pthread_mutexattr_setpshread(&mtx_attr, PTHREAD_PROCESS_SHARED);
pthread_mutex_init(&mutex_in_shared_memory, &mtx_attr);
pthread_mutexattr_destroy(&mtx_attr);

Page updated: June 11, 2026