Home
QNX Software Development Platform
System Architecture
The System Architecture guide accompanies the QNX OS and is intended for both application developers and end-users.
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.
Pulses
In addition to the synchronous Send/Receive/Reply services, the OS also supports fixed-size, nonblocking messages. These are referred to as pulses and carry a small payload.

QNX Momentics IDE User's Guide
QNX Software Development Platform
- 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.
  - 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.
    - Synchronous message passing
      Synchronous messaging is the main form of IPC in the QNX OS.
    - Message copying
      Since our messaging services copy a message directly from the address space of one thread to another without intermediate buffering, the message-delivery performance approaches the memory bandwidth of the underlying hardware.
    - Simple messages
      For simple single-part messages, the OS provides functions that take a pointer directly to a buffer without the need for an IOV (input/output vector). In this case, the number of parts is replaced by the size of the message directly pointed to.
    - Channels and connections
      In the QNX OS, message passing is directed towards channels and connections, rather than targeted directly from thread to thread. A thread that wishes to receive messages first creates a channel; another thread that wishes to send a message to that thread must first make a connection by attaching to that channel.
    - Pulses
      In addition to the synchronous Send/Receive/Reply services, the OS also supports fixed-size, nonblocking messages. These are referred to as pulses and carry a small payload.
    - Priority inheritance and messages
      A server process receives messages and pulses in priority order. As the threads within the server receive requests, they then inherit the priority (but not the scheduling policy) of the sending thread. As a result, the relative priorities of the threads requesting work of the server are preserved, and the server work will be executed at the appropriate priority. This message-driven priority inheritance avoids priority-inversion problems.
    - Message-passing API
      The message-passing API consists of the functions listed here.
    - Robust implementations with Send/Receive/Reply
      Architecting a QNX OS application as a team of cooperating threads and processes via Send/Receive/Reply results in a system that uses synchronous notification. IPC thus occurs at specified transitions within the system, rather than asynchronously.
    - Events
      A significant feature in the kernel design for QNX OS is its subsystem for handling events. POSIX and its realtime extensions define a number of asynchronous notification methods (e.g., UNIX signals that don't queue or pass data, POSIX realtime signals that may queue and pass data, etc.).
    - Signals
      The OS supports the 32 standard POSIX signals (as in UNIX) as well as the POSIX realtime signals, both numbered from a kernel-implemented set of 64 signals with uniform functionality.
    - POSIX message queues
      POSIX defines a set of nonblocking message-passing facilities known as message queues.
    - Shared memory
      Shared memory offers the highest bandwidth IPC available.
    - Typed memory
      POSIX typed memory provides an interface that lets you open named memory objects and perform mapping operations on them.
    - Pipes and FIFOs
      Pipes and FIFOs are both forms of queues that connect processes.
  - 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 is capable of creating 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
- 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 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 OS applications and systems.
Typographical Conventions, Support, and Licensing
This section describes the typographical conventions used throughout the documentation and explains how to obtain technical support.

Pulses

QNX SDP8.0System ArchitectureDeveloperUser

In addition to the synchronous Send/Receive/Reply services, the OS also supports fixed-size, nonblocking messages. These are referred to as pulses and carry a small payload.

Pulses pack a relatively small payload—eight bits (one byte) of code and 64 bits (eight bytes) of data. Pulses are often used to allow servers to notify clients without blocking on them; for example, to notify that data has become available on a hardware device.

Pulse carries a small payload — Figure 1. Pulses pack a small payload.

Page updated: May 17, 2024