Why design patterns ensure reliable multi-tasking in FreeRTOS - Performance Analysis
We want to see how using design patterns affects the time it takes for tasks to run in FreeRTOS.
How does the way we organize code change the work done as tasks increase?
Analyze the time complexity of the following code snippet.
// Simple task creation and queue usage pattern
void Task1(void *pvParameters) {
for (;;) {
xQueueSend(queue, &data, portMAX_DELAY); // send data to queue
vTaskDelay(pdMS_TO_TICKS(100)); // wait 100 ms
}
}
void Task2(void *pvParameters) {
for (;;) {
xQueueReceive(queue, &receivedData, portMAX_DELAY); // receive data
process(receivedData); // handle data
}
}
This code shows two tasks communicating via a queue, a common design pattern in FreeRTOS for safe data sharing.
Identify the loops, recursion, array traversals that repeat.
- Primary operation: The infinite loops in both tasks repeatedly send and receive data through the queue.
- How many times: These loops run indefinitely, repeating as long as the system runs.
As the number of tasks or messages grows, the operations to send and receive data also grow.
| Input Size (number of messages/tasks) | Approx. Operations |
|---|---|
| 10 | About 10 sends and 10 receives |
| 100 | About 100 sends and 100 receives |
| 1000 | About 1000 sends and 1000 receives |
Pattern observation: The work grows directly with the number of messages or tasks communicating.
Time Complexity: O(n)
This means the time to handle communication grows in a straight line with the number of messages or tasks.
[X] Wrong: "Using design patterns makes multitasking instant and cost-free."
[OK] Correct: Even with good patterns, each task and message adds work, so time grows with load.
Understanding how design patterns affect task timing shows you can write code that works well as systems grow.
"What if we replaced the queue with direct task notifications? How would the time complexity change?"