Inter-Task Communication : In real-time operating systems (RTOS), multiple tasks often need to exchange information to function correctly and maintain system reliability. This process is known as inter-task communication (ITC). Effective ITC ensures that tasks can coordinate their actions, share data safely, and avoid issues like data corruption or priority inversion.
What is Inter-Task Communication (ITC) in RTOS?
Inter-task communication is the method by which different tasks (or threads) running in an RTOS exchange information. Unlike general-purpose operating systems, RTOS emphasizes deterministic behavior and timely execution. Therefore, ITC mechanisms in RTOS must be fast, reliable, and predictable.
Why is Inter-Task Communication Important?
- Data Sharing: Tasks often need to access or update shared data.
- Synchronization: Some tasks may need to wait for events or signals from other tasks.
- Resource Management: Helps in managing access to shared hardware resources without conflicts.
- Event Notification: Allows tasks to notify others about the occurrence of specific events.
Common Inter-Task Communication Mechanisms
RTOS provides multiple mechanisms for inter-task communication. Each has its own use case and advantages.
1. Message Queues
- Concept: A message queue is a buffer that stores messages sent by one task and received by another.
- Features: FIFO (First-In-First-Out) order, optional priority-based message handling.
- Use Case: Ideal for sending structured data between producer and consumer tasks.
- Example (Pseudo Code):
// Producer task
msg = "Sensor Data";
sendMessage(queue, msg);
// Consumer task
receivedMsg = receiveMessage(queue);
processData(receivedMsg);
2. Semaphores
- Concept: A semaphore is a signaling mechanism used for synchronization. It can be binary (0 or 1) or counting.
- Features: Prevents race conditions by controlling task access to shared resources.
- Use Case: Protecting a shared resource like a hardware peripheral.
- Example (Pseudo Code):
// Task A
wait(semaphore); // wait until available
accessResource();
signal(semaphore); // release resource
3. Mutexes (Mutual Exclusion)
- Concept: A mutex is similar to a binary semaphore but designed specifically for mutual exclusion.
- Features: Prevents priority inversion with priority inheritance mechanisms.
- Use Case: Ensuring only one task accesses a critical section at a time.
4. Event Flags / Event Groups
- Concept: Event flags are bits used to signal the occurrence of specific events between tasks.
- Features: Multiple tasks can wait for multiple events simultaneously.
- Use Case: Signaling complex event patterns or task dependencies.
5. Shared Memory
- Concept: Tasks share a common memory region for direct data exchange.
- Features: Fast, but requires synchronization (semaphore or mutex) to avoid race conditions.
- Use Case: High-speed data transfer, such as sensor readings or buffers for audio/video streaming.
Real-World Example
Consider a drone system:
- Sensor Task: Reads GPS and IMU data.
- Control Task: Computes motor commands.
- Communication Task: Sends telemetry data to the base station.
Here, message queues can send sensor data from the Sensor Task to the Control Task, while event flags can notify the Communication Task whenever new telemetry data is ready to transmit.
Conclusion
Inter-task communication is a cornerstone of real-time systems. By using mechanisms like message queues, semaphores, mutexes, event flags, and shared memory, developers can ensure that tasks work together efficiently and safely. Understanding ITC not only improves system reliability but also enhances the predictability and performance of RTOS-based applications.
FAQ Inter-Task Communication (ITC) in RTOS
1) What is inter-task communication in an RTOS?
Inter-task communication (ITC) is how tasks (threads) exchange data and coordinate actions. It covers two needs:
- Data passing (e.g., sensor values from Producer → Consumer)
- Synchronization (e.g., “I’m done, you can start”)
2) Why not just use global variables?
Unprotected globals cause race conditions, data corruption, and timing bugs. RTOS primitives (queues, semaphores, mutexes, etc.) provide atomicity, ordering, and blocking with timeouts.
3) What are the most common ITC mechanisms?
- Queues / Mailboxes / Message queues – pass data/messages in FIFO order.
- Semaphores – signaling (binary) and counting (resource tokens).
- Mutexes – mutual exclusion with priority inheritance for shared data.
- Event flags (event groups) – bitwise signals; wait for any/all events.
- Pipes/Streams – byte streams.
- Shared memory + synchronization – fastest but you must lock correctly.
- Message buffers/ring buffers – lightweight, often lock-free for single-producer/single-consumer.
4) Queue vs. mailbox vs. message buffer—what’s the difference?
- Queue: fixed-size slots; each item same size; strict FIFO.
- Mailbox: like a queue but often single-slot or small count; can carry pointers.
- Message buffer/stream: variable-length messages serialized into a FIFO buffer.
5) When should I use a semaphore vs. a mutex?
- Semaphore (binary): general signal (e.g., ISR → task) or counting for identical resources (N tokens).
- Mutex: protect critical sections; supports priority inheritance to mitigate priority inversion.
6) Can an ISR use these mechanisms?
Yes, but only ISR-safe APIs (often suffixed with FromISR). Typically:
- Give semaphores/queues to wake a task.
- Keep ISR handlers short; move heavy work to a task.
FreeRTOS example (ISR → Task using a binary semaphore):
// Global
SemaphoreHandle_t xSem;
void ISR_Handler(void) {
BaseType_t xHPW = pdFALSE;
xSemaphoreGiveFromISR(xSem, &xHPW);
portYIELD_FROM_ISR(xHPW);
}
void TaskWaiter(void *arg) {
for (;;) {
if (xSemaphoreTake(xSem, pdMS_TO_TICKS(50)) == pdTRUE) {
// Handle the event
} else {
// Timeout handling
}
}
}
7) How do queues work in practice?
A producer pushes data; a consumer blocks until data arrives or timeout expires.
FreeRTOS queue example (Producer/Consumer):
typedef struct { uint32_t ts; int16_t temp; } Sample_t;
QueueHandle_t q;
void Producer(void *arg) {
Sample_t s;
for (;;) {
s.ts = xTaskGetTickCount();
s.temp = read_temp();
xQueueSend(q, &s, pdMS_TO_TICKS(10)); // non-blocking-ish
vTaskDelay(pdMS_TO_TICKS(100));
}
}
void Consumer(void *arg) {
Sample_t s;
for (;;) {
if (xQueueReceive(q, &s, portMAX_DELAY) == pdTRUE) {
process_sample(s);
}
}
}
8) What are event flags and when should I use them?
Event flags are bits representing conditions (BIT0, BIT1, …). Tasks can wait for any or all bits, optionally with clear-on-exit. Great for multi-source synchronization without moving data.
FreeRTOS EventGroup example:
#define EVT_WIFI (1<<0)
#define EVT_TIME (1<<1)
EventGroupHandle_t eg;
void TaskCoordinator(void *arg) {
EventBits_t bits = xEventGroupWaitBits(eg, EVT_WIFI|EVT_TIME, pdTRUE, pdTRUE, portMAX_DELAY);
// Runs when both Wi-Fi ready and time synced
}
9) What’s priority inversion and how do I avoid it?
A low-priority task holds a lock needed by a high-priority task, causing the high-priority task to wait behind a medium-priority task. Use mutexes with priority inheritance (not semaphores) for shared data.
10) What’s the best way to pass large data (e.g., frames)?
Pass pointers through a queue/mailbox to pre-allocated buffers (from a memory pool) instead of copying big payloads. This is a zero-copy pattern. Guard the buffer lifetime (who owns/free’s it).
11) How do timeouts help reliability?
Every blocking call should have a finite timeout to avoid deadlocks and detect stalls. On timeout, log, count errors, and apply recovery (reset peripheral, drop message, escalate).
12) How big should my queue be?
Profile producer/consumer rates and worst-case bursts. Rule of thumb:
depth ≥ (burst size) + (max producer - consumer backlog during blocking)
Add margin for jitter; monitor queue high-water mark at runtime.
13) Can I use shared memory without locks if I’m careful?
Only in single-producer/single-consumer with a lock-free ring buffer and proper volatile/compiler barriers or RTOS primitives. For multi-producer or multi-consumer, use locks or specialized lock-free structures.
14) Are message queues deterministic enough for hard real-time?
Yes—if sized properly, with bounded operations, ISR-safe signaling, and no dynamic allocation in the hot path. Avoid variable-time copies; prefer fixed sizes or zero-copy pools.
15) What’s the difference between blocking and non-blocking APIs?
- Blocking waits until success/timeout; simpler logic but can delay tasks.
- Non-blocking returns immediately; requires retries or event-driven designs.
Use blocking with sensible timeouts for simplicity; use non-blocking in high-rate pipelines.
16) How do I choose between queues and event flags?
- Need to carry data? → Queue/Message buffer
- Need to signal states or gate progress? → Semaphore/Event flags
Often you’ll signal with an event and then read from a shared buffer.
17) Example with POSIX message queues (RTOSes with POSIX layer)
#include <mqueue.h>
typedef struct { int id; float val; } msg_t;
mqd_t mq;
struct mq_attr attr = { .mq_flags=0, .mq_maxmsg=8, .mq_msgsize=sizeof(msg_t), .mq_curmsgs=0 };
void setup() {
mq = mq_open("/sensorq", O_CREAT | O_RDWR, 0644, &attr);
}
void producer() {
msg_t m = { .id=1, .val=3.14f };
mq_timedsend(mq, (char*)&m, sizeof(m), 0, &(struct timespec){.tv_sec=0,.tv_nsec=1000000});
}
void consumer() {
msg_t m;
ssize_t n = mq_timedreceive(mq, (char*)&m, sizeof(m), NULL, &(struct timespec){.tv_sec=1,0});
if (n > 0) handle(m);
}
18) How do I debug ITC issues?
- Enable RTOS trace hooks and queue/semaphore stats.
- Log timeouts, drops, queue depths.
- Add asserts on return codes.
- Use watchpoints on shared buffers and stack watermarking.
19) What pitfalls should I avoid?
- Using a binary semaphore as a lock (use a mutex).
- Dynamic allocation in ISR or hot loops → fragmentation/jitter.
- Unbounded message sizes or unvalidated pointers.
- Forgetting ownership—who frees a message buffer?
- Ignoring priority inheritance → inversion.
20) What’s a clean architecture for ITC in embedded apps?
- Drivers/ISRs push events or buffer pointers to queues.
- Workers process and publish results via queues/mailboxes.
- Supervisors wait on event groups and orchestrate modes.
- Shared data guarded by mutexes; larger payloads via memory pools.
You can also Visit other tutorials of Embedded Prep
