POSIX message queues are identified by filesystem paths (e.g., /my_queue) and use functions like mq_open(), mq_send(), and mq_receive(). They support message priorities (0-lower to higher) and can deliver asynchronous notifications via signals or thread callbacks. System V message queues are identified by integer keys obtained via ftok() and use msgget(), msgsnd(), and msgrcv(). They use the mtype field for selective message filtering rather than priority. POSIX queues have a cleaner API and better Linux integration; System V queues are more portable across Unix variants and offer operations like message undo (IPC_STAT, IPC_SET). Both preserve message boundaries and support async send/receive with non-blocking flags.

When a message queue reaches its maximum capacity (either mq_maxmsg messages or mq_msgsize * mq_maxmsg total bytes for POSIX; MSGMNB and msg_qbytes for System V), a mq_send() or msgsnd() call blocks until a receiver removes messages and frees space. If the queue was opened with a non-blocking flag (MQ_DONTWAIT or IPC_NOWAIT), the call instead returns -1 with errno=EAGAIN. No messages are silently dropped. Applications should monitor queue fill levels via mq_getattr() or msgctl(MSG_STAT) and implement appropriate backpressure strategies when queues approach capacity.

Pipes are byte streams with no inherent structure — if a writer sends 100 bytes then 50 bytes, the reader might receive 150 bytes at once, or 50 bytes followed by 100 bytes, or any other division. There are no message boundaries. Message queues, by contrast, treat each send() as a discrete message with a defined length. When a receiver calls mq_receive() or msgrcv(), it gets exactly one complete message as a unit — the kernel preserves the boundary. This makes message queues ideal for discrete task messages, command packets, or any scenario where the unit of data matters. For streaming data, pipes are more efficient; for discrete messages, queues are more appropriate.

Linux enforces several system-wide limits for System V message queues, configurable via /proc/sys/kernel/*:

• msgmni: Maximum number of message queues system-wide
• msgmax: Maximum size of a single message in bytes
• msgtql: Maximum total bytes in all queues combined
• msgmnb: Maximum bytes in a single queue (default typically 16384 bytes)

POSIX message queue limits are per-queue and specified at creation time (mq_maxmsg and mq_msgsize), bounded by the process's file descriptor limit and system-wide /proc/sys/fs/mqueue/msg_max and queue_max. Exceeding these limits causes mq_open() or mq_send() to fail with appropriate error codes.

mq_notify() registers a notification that is delivered when a message arrives on an empty queue. The notification can be delivered as a signal (typically SIGRTMIN) or by invoking a thread callback (SIGEV_THREAD). Only one process can register for notification at a time — calling it again replaces the previous registration. After a notification is delivered, you must re-register if you want continued notifications. This makes mq_notify() useful for event-driven servers that want to avoid polling with mq_receive() in a tight loop.

A work queue using message queues works like this:

1. Server process creates a message queue and loops calling mq_receive()
2. Client processes open the same queue and send work messages (containing task parameters) with mq_send()
3. Each client can send multiple messages without waiting for results — achieving async decoupling
4. Server processes tasks in order, optionally sending results to a separate response queue or via another channel

For priority-based work distribution, use message priority levels so urgent tasks (e.g., interactive requests) jump ahead of background jobs. For result delivery, either use a separate response queue per client, include a reply-to path in the message, or switch to a full request-reply pattern using sockets. The key advantage over pipes is that the server does not need to be running when clients submit work — messages queue up and wait.

Priority inversion occurs when a low-priority process holds a resource (in this case, a message queue) that a high-priority process needs, and an medium-priority process preempts the low-priority one, effectively blocking the high-priority process indirectly. Example: a low-priority task fills a message queue, then gets preempted by a medium-priority background job, and a high-priority task trying to send to the same queue blocks. In message queue systems, priority inversion is typically addressed by priority inheritance (the kernel temporarily boosts the low-priority holder's scheduling priority) or by careful queue design — keeping queue depths shallow and processing times bounded. POSIX message queues on Linux do not implement priority inheritance in the kernel, so applications must be aware of this when mixing high and low priority producers/consumers on the same queue.

ftok(path, project_id) generates a System V IPC key from a path (typically a directory or executable) and a single character project identifier. The algorithm takes the st_dev and st_ino of the path (device number and inode number) and XORs them with the project_id cast to a specific bit pattern. The result is an key_t integer that can be used with msgget() to obtain or create a queue. Pitfalls: (1) if the path's filesystem is remastered or the inode numbers change (backup restore, different filesystem), the same path produces a different key and the queue cannot be found. (2) if two unrelated applications use the same path and project_id, they collide and share a queue unexpectedly. (3) ftok() on a path that doesn't exist returns (key_t)-1. Use a path to a known executable or a directory guaranteed to persist and be unique per application.

msgctl(msgid, cmd, buf) performs control operations on a System V message queue. Commands include: IPC_STAT — copy queue metadata into buf (permissions, size limits, PID of last msgsnd/msgrcv). IPC_SET — modify queue permissions and owner (only by privileged user). IPC_RMID — remove the queue from the kernel immediately, waking all blocked senders/receivers with error return. IPC_INFO — get system-wide queue limits. Security implications: IPC_SET can change queue permissions to allow unauthorized access; IPC_RMID destroys all queued messages without warning. The operation requires the caller to have the same effective UID as the queue creator, or CAP_IPC_OWNER capability. In shared hosting environments, a user with access to /proc/sysvipc/msg can discover queue IDs and attempt msgctl() operations — this is why containerized environments often restrict IPC facilities.

Sending a message larger than the queue's mq_msgsize attribute causes mq_send() to fail with EMSGSIZE. Unlike receive truncation (which can also fail), the queue stores the exact message size — it cannot accommodate a message larger than mq_msgsize even if only a few bytes over. This is why mq_getattr() should be called after mq_open() to retrieve mq_msgsize and enforce message size limits at the application layer. Applications should validate message sizes before calling mq_send(), and if variable-size messages are needed, define a maximum payload and set mq_msgsize to that maximum plus overhead for metadata. Note that the size limit is per-message, not cumulative — the queue can hold many messages up to mq_maxmsg each.

mq_getattr(mqd, attr) retrieves the current queue attributes (flags, maxmsg, msgsize, curmsgs) into the mq_attr struct passed. mq_setattr(mqd, attr, old_attr) sets queue attributes — specifically, only the mq_flags field can be modified (non-blocking mode). All other fields (mq_maxmsg, mq_msgsize, mq_curmsgs) are read-only after queue creation. Use mq_getattr() to query the queue's message size and current message count for application-level flow control. Use mq_setattr() to toggle O_NONBLOCK on an already-open queue — for example, to temporarily switch to non-blocking mode to drain the queue without blocking, then restore blocking mode. Note that mq_setattr() with old_attr non-null will fill in the previous attributes if you need them.

Unix domain sockets (socketpair(), AF_UNIX) support bidirectional communication and connection-oriented streams (like TCP) or datagrams (like UDP) — they can preserve message boundaries with AF_UNIX/SOCK_DGRAM but not as naturally as message queues. Message queues are unidirectional and persistent — a sender can deposit messages before any receiver exists. For high-throughput streaming (shuttling large volumes of data between processes), Unix domain sockets with SOCK_SEQPACKET offer lower latency than message queues because the kernel implements zero-copy optimizations for socket buffers. For discrete task messages with async delivery and priority, message queues are simpler. For full-duplex communication with client/server patterns, Unix domain sockets are more capable. Both live in kernel memory and have system-wide resource limits.

For POSIX queues, limits are specified per-queue at creation time within system-wide constraints. The system-wide ceiling for POSIX queue bytes and count is in /proc/sys/fs/mqueue/ (e.g., msg_max for max messages per queue, queues_max for max number of queues). For System V, MSGMNB is the max bytes per queue, MSGMAX is max bytes per message, MSGMNI is max queues system-wide, and MSGTQL is total messages across all queues. Choosing values: estimate your worst-case message size and multiply by your desired queue depth — if messages are 1KB and you want to handle 100-packet bursts, set 100KB minimum. Account for kernel memory overhead (each message has metadata overhead). In embedded or RTOS contexts, these limits are much smaller — sometimes just a few kilobytes total. Monitor actual usage with ipcs -q for System V or mq_getattr() for POSIX.

Deadlocks in message queue scenarios typically occur when two processes each wait for a message from the other on different queues — a classic two-phase commit problem. Mitigation: design message patterns where one side is always the initiator (producer sends, consumer receives, never the reverse on the same queue pair). Race conditions: if a consumer reads a message and crashes before processing it, the message is lost — use a dedicated acknowledgment response queue, or store messages in the queue with a transaction flag that the sender clears only after an explicit ack. For multi-process consumers, use msgrcv() with IPC_NOWAIT inside a loop with a mutex-protected queue drain to avoid two processes receiving the same message. Use atomic operations or file-based locking for coordinating access to shared queue identifiers. Always handle EIDRM (queue removed) and EAGAIN (queue empty) gracefully in non-blocking code paths.

System V mtype is a message classification field (a positive long) used for selective receive — msgrcv(msgid, &msg, size, mtype, msgtyp) with msgtyp=5 will only retrieve messages with mtype == 5. This enables type-based routing: a server can listen for command messages of type 1 while routing data messages of type 2 to a different handler. POSIX queues have mq_send(mq, msg, len, priority) where priority (0-lower to higher) determines delivery order — a mq_receive() always gets the highest-priority message currently in the queue, regardless of submission order. The key difference: System V's mtype is exact matching for message routing, while POSIX priority controls ordering within the queue. You can simulate POSIX-style priority with System V by using message types as priority levels (e.g., type 1 = high, type 5 = low) and using a receive pattern that consumes highest types first.

Both POSIX and System V message queues are implemented as linked lists of message structs inside kernel memory. Each message has a header (type, size, timestamp, pointers for the doubly-linked list) followed by the payload. On msgsnd/mq_send(), the kernel allocates a message struct, copies the user payload into kernel memory via copy_from_user(), links it into the list (at the tail for System V, sorted by priority for POSIX), and marks any waiting receivers as runnable. On msgrcv/mq_receive(), the kernel unlinks the message from the list, copies the payload to user space via copy_to_user(), frees the message struct, and marks any waiting senders as runnable. The double-copy (user to kernel, kernel to user) is the main performance cost — for high-frequency small messages, this overhead dominates. Shared memory with custom synchronization avoids the copy at the cost of more complex application logic. Queue operations also require kernel context switches, which adds latency compared to shared memory approaches.

Message queue operations may fall outside standard filesystem audit logging since queues are kernel objects tracked via IPC mechanisms, not files. In regulated environments (PCI-DSS, HIPAA, SOC2), consider: (1) application-level logging — wrap every mq_send() and mq_receive() in logging calls that record queue name, timestamp, sender/receiver PID, and message metadata (not payload if sensitive). (2) queue access controls — POSIX queues respect filesystem permissions on /dev/mqueue; restrict access with appropriate 0660 permissions. (3) data classification — message payloads containing PII, financial data, or credentials should not be placed in queues without encryption, since any process with queue access can read messages. (4) retention — message queues do not persist across reboots; for compliance records that require durable audit trails, write confirmation records to a database or append-only log after each queue operation. (5) monitoring — set up alerts for queue depletion or near-capacity conditions that might indicate an attack filling queues as a DoS vector.

Choose a message broker over kernel message queues when you need: durability — kernel queues lose messages on reboot, while Kafka/RabbitMQ persist to disk with replication. cross-machine communication — kernel queues are single-host IPC; message brokers speak TCP/HTTP and can route across network boundaries. clustering and HA — brokers support multi-node clusters with leader election and automatic failover. rich routing — topics, exchanges, dead-letter queues, TTL, message transformations. delivery guarantees — at-least-once or exactly-once semantics with acknowledgments and redelivery. horizontal scaling — multiple consumer groups consuming in parallel with partition-based parallelism. Use kernel message queues for: low-latency single-host IPC between known processes, simple producer-consumer patterns within a single machine, cases where the simplicity of mq_* calls outweighs the need for advanced features, and embedded/RTOS environments where a full broker is too heavy.

On POSIX message queues, mq_send(mqd, msg, len, priority) inserts messages based on priority order — higher numeric priority values are inserted ahead of lower-priority ones. The queue is sorted by priority (typically descending), with FIFO ordering for messages of equal priority. So a message with priority 10 inserted after a priority 5 message will be received before that 5-priority message. This enables urgent message jumping ahead of normal messages — an interrupt handler or critical task can send priority 255 messages that get processed immediately even if many priority 0 messages are queued. The priority value range is defined by the queue's attributes (typically 0 to a system-defined maximum, often 32 or 65535). If message ordering among same-priority messages matters, consider including a monotonic sequence number in the message payload to detect reordering if needed.

Graceful cleanup requires coordination: (1) define a shutdown protocol — for example, send a special "shutdown" message with a specific type that each consumer recognizes as the signal to exit. (2) track which processes have the queue open via mq_getattr()'s mq_curmsgs and monitor for zero before unlinking. (3) use reference counting in shared memory or a separate coordination file to know when all processes have finished. (4) have one designated owner process responsible for calling mq_unlink() after a timeout or when the work is done — never call mq_unlink() while other processes might still need the queue. (5) handle EIDRM (queue was unlinked by another process) and EBADF (queue was closed) as normal termination conditions in your receive loop. For System V, msgctl(msgid, IPC_RMID) marks the queue for deletion immediately but it persists until the last process closes it — so other processes can continue to use it until they all call msgctl() or exit. Use atexit() handlers or signal handlers (SIGTERM) to ensure cleanup happens on graceful shutdown.