POSIX message queues

POSIX message queues
Name	POSIX message queues
Acronym	POSIX MQ
Introduced	1994
Standard	IEEE 1003.1
Filetype	IPC object
Implementations	GNU C Library, glibc, musl, FreeBSD, NetBSD, macOS (limited), Linux (mqueue)
License	system-dependent

POSIX message queues provide an interprocess communication mechanism standardized by IEEE that enables processes to exchange discrete messages via named queues. They offer asynchronous, message-oriented IPC with priorities, notification, and optional blocking semantics, complementing pipes, sockets, and System V IPC. Implementations appear in UNIX-like systems and are referenced in POSIX.1 and the Single UNIX Specification; kernel and library behavior varies across IEEE, The Open Group, GNU Project, Linux Foundation, and several academic and industrial operating system projects.

Overview

POSIX message queues are specified in IEEE 1003.1 and the Single UNIX Specification maintained by IEEE and The Open Group, and were influenced by earlier work at Bell Labs and research in operating system design at institutions such as MIT and UC Berkeley. They expose named queue objects, accessible via filesystem-like identifiers, that allow processes to send and receive fixed-size messages with associated priorities. The design contrasts with System V message queues and stream-based APIs used by projects like BSD and Sun Microsystems's offerings, offering clearer semantics for priority and asynchronous notification used in embedded systems from vendors such as Wind River.

API and Interfaces

Portable programs use functions defined in provided by libraries such as GNU C Library and musl to manipulate queue objects. Key functions include mq_open, mq_close, mq_unlink, mq_send, mq_receive, mq_getattr, mq_setattr, mq_notify, and mq_timedsend/mq_timedreceive. These interfaces interact with system calls implemented in kernels like the Linux kernel and FreeBSD kernel; libraries often wrap low-level primitives exposed by vendors including Oracle Corporation (Solaris) and projects such as NetBSD. POSIX attributes (mq_attr) control mq_maxmsg and mq_msgsize; struct timespec uses specifications from IEEE 1003.1 for timed operations. Notifications may invoke function-style callbacks in process contexts managed by systemd or signal delivery via SIGEV_SIGNAL or thread creation via SIGEV_THREAD semantics.

Behavior and Semantics

Message ordering follows priority-based semantics: messages with higher priority are dequeued before lower priority messages, though FIFO ordering applies within equal priority classes. Blocking behavior is governed by flags such as O_NONBLOCK and by kernel capacity parameters; senders may block when the queue is full and receivers block when the queue is empty. Notification registration is single-subscriber per queue; mq_notify semantics resemble event registration models used by kqueue and epoll in FreeBSD and Linux respectively. Error handling uses standard errno values like EAGAIN, EMSGSIZE, and ETIMEDOUT specified by POSIX; interrupted calls may return EINTR. The API intentionally separates message boundaries from stream semantics found in interfaces by Berkeley sockets.

Implementation and Kernel Support

Implementations range from kernel-resident queue management (Linux mqueue filesystem) to user-space emulation layered on shared memory and semaphores used historically by GNU Hurd and some embedded RTOS vendors. Linux implements POSIX message queues as a virtual filesystem (mqueue), managed by the vfs layer and maintained by the Linux kernel community. BSD derivatives often provide native kernel support integrated with existing IPC subsystems developed at UC Berkeley. Real-time and embedded vendors such as Wind River Systems and QNX Software Systems supply tailored implementations with deterministic timing guarantees, sometimes certified against standards used by FAA or IEC safety profiles.

Security and Access Control

Access control for named queues commonly uses filesystem-style permissions (owner, group, other) and mode bits interpreted by library wrappers; implementations consult credential information from kernel modules maintained by projects like Linux kernel and FreeBSD's authentication subsystems. Visibility and lifetime rules can be influenced by namespace mechanisms such as Linux namespaces (containers) developed by contributors affiliated with Docker, Inc. and Red Hat, Inc.. Because notification can deliver signals, integration with privilege models from SELinux and AppArmor-style frameworks affects allowable operations in hardened environments. Auditing and capability restrictions may be enforced by mechanisms derived from POSIX.1e capabilities work and platform-specific security extensions.

Performance and Limitations

Performance characteristics depend on kernel vs. user-space implementation, locking strategies, and underlying scheduling facilities. Kernel implementations (Linux, BSD) typically outperform user-space emulation because they avoid extra copies and context switches; however, excessively large mq_msgsize or high message rates can stress allocator and scheduler subsystems developed by the Linux kernel and FreeBSD communities. Limitations include finite mq_maxmsg and mq_msgsize parameters, single-subscriber notification, and potential priority inversion issues addressed by real-time extensions from IEEE 1003.1 and vendors such as Wind River. Debugging and profiling often leverage tools from GNU Project and Linux Foundation ecosystems.

Compliance and Standards

The normative specification appears in IEEE 1003.1 and the Single UNIX Specification maintained by The Open Group; conformance testing is exercised by test suites produced by organizations like The Open Group and open-source communities in coordination with IEEE working groups. Platform conformance varies: mainstream UNIX-like systems provide partial or full support, while some POSIX-certified systems supply additional real-time semantics outlined in standards originating from IEEE working groups and industrial consortia.

Category:Inter-process communication