Task notification vs queue performance in FreeRTOS - Practice Questions

Challenge - 5 Problems

❓ Predict Output

intermediate

Task Notification vs Queue: Which is faster?

Consider two FreeRTOS tasks communicating data. One uses a task notification to send a single integer value, the other uses a queue to send the same integer. What is the expected difference in performance?

Given the code snippets below, which output best describes the timing results?

FreeRTOS

/* Task Notification example */
uint32_t value = 42;
xTaskNotify(taskHandle, value, eSetValueWithOverwrite);

/* Queue example */
uint32_t value = 42;
xQueueSend(queueHandle, &value, 0);

A Task notification is faster because it uses direct-to-task signaling with minimal overhead, while queues involve copying data and managing queue structures.

B Queue is faster because it supports multiple items and task notifications are limited to one value, causing delays.

C Both have the same performance since both use interrupts internally to signal tasks.

D Task notification is slower because it requires more CPU cycles to manage the notification bits compared to queues.

💡 Hint

Think about how much data copying and synchronization each method requires.

Task notifications are designed for fast, lightweight signaling between tasks. They avoid the overhead of copying data into a queue and managing queue pointers, making them faster for simple data like integers.

🧠 Conceptual

intermediate

When to prefer task notifications over queues?

Which scenario best fits the use of task notifications instead of queues in FreeRTOS?

A When sending large amounts of data between tasks frequently.

B When tasks require guaranteed message order and buffering of multiple messages.

C When multiple tasks need to receive the same message simultaneously.

D When signaling a task with a simple event or a single integer value without data buffering needs.

💡 Hint

Task notifications are lightweight and limited in data size.

Task notifications are ideal for simple signaling or passing a single integer value. Queues are better for buffering multiple messages or larger data.

❓ Predict Output

advanced

Output of task notification value after multiple sends

Given the following FreeRTOS code snippet, what is the value received by the task after two notifications?

FreeRTOS

uint32_t ulValue;

// Task waits for notification and reads value
xTaskNotifyWait(0x00, 0xffffffff, &ulValue, portMAX_DELAY);

// Elsewhere in code:
xTaskNotify(taskHandle, 5, eSetValueWithOverwrite);
xTaskNotify(taskHandle, 3, eSetValueWithOverwrite);

A 0

B 5

C 3

D 8

💡 Hint

Check how eSetValueWithOverwrite affects the notification value.

eSetValueWithOverwrite replaces the notification value with the new one. The second call overwrites the first, so the task receives 3.

❓ Predict Output

advanced

Queue length after multiple sends and receives

What is the length of the queue after the following operations?

FreeRTOS

QueueHandle_t queue = xQueueCreate(3, sizeof(int));
int val = 10;
xQueueSend(queue, &val, 0);
val = 20;
xQueueSend(queue, &val, 0);
int received;
xQueueReceive(queue, &received, 0);
xQueueSend(queue, &val, 0);

A 3

B 2

C 0

D 1

💡 Hint

Count how many items are sent and received.

Two items are sent initially, one is received (removed), then one more is sent. So total items in queue: 2.

🧠 Conceptual

expert

Why might task notifications be unsuitable for complex data transfer?

Which is the main reason task notifications are not recommended for transferring complex or large data between tasks?

A Task notifications can only send a 32-bit value and do not support buffering multiple messages.

B Task notifications require dynamic memory allocation which is slow for large data.

C Task notifications block the scheduler causing delays in other tasks.

D Task notifications automatically copy data which increases CPU usage.

💡 Hint

Think about the size and buffering capabilities of task notifications.

Task notifications are limited to a single 32-bit value and do not provide buffering, making them unsuitable for complex or large data transfers.