Message queues, event queues, and mailboxes are components used for communication in software systems that represent a queue of messages or events that are awaiting processing. These components can be used for communication between components in the same process, inter-process communication, or communication across subsystems in a distributed system.
Queues may be provided by an OS, a library, or messaging middleware. In any case, a message queue stores a series of messages of some variety (data, notifications, requests, etc.) in FIFO order. Rather than making direct synchronous calls, messages are added to a queue and processed asynchronously at a later time, whether directly by another thread or in an event loop or message pump.
Table of Contents:
Known Uses
Message queues are a core component of message passing and the publish-subscribe pattern. Communication between modules, tasks, and sub-systems can occur through message queues (whether directly or mediated by a central broker).
Message queues are helpful in event-driven and asynchronous programming styles. The use of queues helps to decouple when a message or event is sent from when it is processed – publishers can submit information to a queue or broker without waiting for a response or blocking the current thread of control.
Message queues are also helpful in general to keep modules decoupled from one another – rather than directly invoking APIs provided by another module, data can be sent to a queue instead. The module submitting to the queue does not require any knowledge about who is going to eventually process that data.o
Implementation Details
When using message queues, the following concerns need to be considered:
- What goes into the queue?
- What is the lifetime/ownership of data stored in the queue?
- Who has read/write access?
What goes into the queue?
- Are you storing events/notifications (e.g., X happened in case you want to respond), requests/messages (e.g., please make X happen), or data?
- What is the format of the message?
- Will you store pointers or values?
- Do you need to encode other information so that the receiver can properly route or filter the information based on interest?
What is the lifetime/ownership of data stored in the queue?
You will need to consider whether:
- Data is copied into the queue by value.
- Data and messages are provided through the queue itself.
- Ownership is passed to the queue – that is, when the message is enqueued, the queue now has ownership and the sender no longer owns it. When the message is dequeued, the receiver owns the data and must manage it.
- Ownership is shared, and memory is cleaned up via reference counting or other garbage collection strategies.
Who has read/write access?
In other words, will there be one writer or multiple writers? One receiver or multiple receivers?
If using a single writer, receivers know the source of the data. If using multiple writers (e.g., you have single, central event bus), you will probably want to include a reference to the sender in the message payload.
With a single reader, the queue is essentially an encapsulated implementation detail of the reader, and you know the reader will process all messages so that you do not need to implement any type of filtering logic. In a broadcast style, where multiple listeners all receive the same data from the queue, you will probably need to add in message filtering capabilities so that listeners will be able to filter messages based on their interest. Alternatively, if you are using a mailbox system that will dispatch messages/events to the proper thread, you will need to know the target for a given message so that it can be dispatched appropriately.
With multiple readers and/or writers, you need to ensure that you have proper synchronization protections in place to prevent data races on the queue.
References
- Message queue – Wikipedia
In computer science, message queues and mailboxes are software-engineering components typically used for inter-process communication (IPC), or for inter-thread communication within the same process. They use a queue for messaging – the passing of control or of content. Group communication systems provide similar kinds of functionality.
- Event Queue · Decoupling Patterns · Game Programming Patterns
Intent: Decouple when a message or event is sent from when it is processed.
[…]
Like many patterns, event queues go by a number of aliases. One established term is “message queue”. It’s usually referring to a higher-level manifestation. Where our event queues are within an application, message queues are usually used for communicating between them.
[…]
A queue stores a series of notifications or requests in first-in, first-out order. Sending a notification enqueues the request and returns. The request processor then processes items from the queue at a later time. Requests can be handled directly or routed to interested parties. This decouples the sender from the receiver both statically and in time.
Using Message Queues
- Embedded Software Design by Jacob Beningo
Another technique developers can use to limit telemetry from turning an elegant architecture into a giant ball of mud is to treat telemetry as a service. Developers can create a telemetry task that treats the telemetry data structure as a private data member. The only way to update the telemetry data is to receive telemetry data updates from other tasks in the system through a telemetry message queue.
« Back to Glossary Index