Rendezvous (sync) pattern in FreeRTOS - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

Output of Rendezvous synchronization with two tasks

Consider two FreeRTOS tasks using a binary semaphore to synchronize at a rendezvous point. What will be the output sequence printed by the tasks?

FreeRTOS

#include "FreeRTOS.h"
#include "task.h"
#include "semphr.h"
#include <stdio.h>

SemaphoreHandle_t xSemaphore;

void Task1(void *pvParameters) {
    printf("Task1: Start\n");
    xSemaphoreGive(xSemaphore); // Signal Task2
    xSemaphoreTake(xSemaphore, portMAX_DELAY); // Wait for Task2
    printf("Task1: End\n");
    vTaskDelete(NULL);
}

void Task2(void *pvParameters) {
    xSemaphoreTake(xSemaphore, portMAX_DELAY); // Wait for Task1
    printf("Task2: Start\n");
    xSemaphoreGive(xSemaphore); // Signal Task1
    printf("Task2: End\n");
    vTaskDelete(NULL);
}

int main() {
    xSemaphore = xSemaphoreCreateBinary();
    xTaskCreate(Task1, "Task1", 1000, NULL, 1, NULL);
    xTaskCreate(Task2, "Task2", 1000, NULL, 1, NULL);
    vTaskStartScheduler();
    return 0;
}

A

Task1: Start
Task2: End
Task2: Start
Task1: End

B

Task1: Start
Task1: End
Task2: Start
Task2: End

C

Task2: Start
Task2: End
Task1: Start
Task1: End

D

Task1: Start
Task2: Start
Task2: End
Task1: End

💡 Hint

Think about how the semaphore controls the order of execution between the two tasks.

Task1 starts and signals Task2 by giving the semaphore. Task2 waits for the semaphore, then starts and signals back to Task1. This ensures Task2's start and end print statements happen between Task1's start and end.

🧠 Conceptual

intermediate

Purpose of Rendezvous pattern in FreeRTOS

What is the main purpose of using the Rendezvous (synchronization) pattern in FreeRTOS task design?

A To synchronize two or more tasks so they wait for each other at a certain point before continuing

B To create a deadlock situation intentionally for testing

C To increase the priority of one task over others permanently

D To allow tasks to run completely independently without waiting for each other

💡 Hint

Think about what synchronization means in multitasking.

The Rendezvous pattern ensures tasks wait for each other at a synchronization point, so they proceed together only after all have reached that point.

🔧 Debug

advanced

Identify the error causing deadlock in Rendezvous implementation

Given the following FreeRTOS code snippet implementing a rendezvous with two tasks, identify the cause of deadlock:

FreeRTOS

#include "FreeRTOS.h"
#include "task.h"
#include "semphr.h"
#include <stdio.h>

SemaphoreHandle_t xSemaphore1, xSemaphore2;

void TaskA(void *pvParameters) {
    printf("TaskA: Before sync\n");
    xSemaphoreGive(xSemaphore1);
    xSemaphoreTake(xSemaphore2, portMAX_DELAY);
    printf("TaskA: After sync\n");
    vTaskDelete(NULL);
}

void TaskB(void *pvParameters) {
    printf("TaskB: Before sync\n");
    xSemaphoreTake(xSemaphore1, portMAX_DELAY);
    xSemaphoreGive(xSemaphore2);
    printf("TaskB: After sync\n");
    vTaskDelete(NULL);
}

int main() {
    xSemaphore1 = xSemaphoreCreateBinary();
    xSemaphore2 = xSemaphoreCreateBinary();
    xTaskCreate(TaskA, "TaskA", 1000, NULL, 1, NULL);
    xTaskCreate(TaskB, "TaskB", 1000, NULL, 1, NULL);
    vTaskStartScheduler();
    return 0;
}

A Both tasks wait on each other's semaphore without any initial give, causing deadlock

B TaskB takes xSemaphore1 before TaskA gives it, causing TaskB to block until TaskA runs

C TaskA gives xSemaphore1 before TaskB takes it, causing TaskB to block forever

D The semaphores are not created before tasks start, causing null pointer dereference

💡 Hint

Check if any semaphore is given before the other task tries to take it.

Both semaphores start empty. TaskA gives xSemaphore1, TaskB waits on it. TaskB gives xSemaphore2, TaskA waits on it. But if TaskA runs first and gives xSemaphore1, TaskB can proceed. However, if TaskB runs first and tries to take xSemaphore1 before TaskA gives it, it blocks. This can cause deadlock if scheduling is unlucky.

📝 Syntax

advanced

Identify the syntax error in Rendezvous semaphore usage

Which option contains a syntax error in the semaphore take/give calls for FreeRTOS rendezvous pattern?

A xSemaphoreGive(xSemaphore);

B xSemaphoreTake(xSemaphore portMAX_DELAY);

C xSemaphoreTake(xSemaphore, portMAX_DELAY);

D ;)erohpameSx(eviGerohpameSx

💡 Hint

Check the syntax of function calls and commas.

Option B is missing a comma between parameters in xSemaphoreTake call, causing a syntax error.

🚀 Application

expert

Number of synchronization points in a multi-task rendezvous

In a FreeRTOS system, four tasks must synchronize at a rendezvous point so that none proceeds until all have reached it. Using binary semaphores for pairwise synchronization, how many semaphore give/take operations are needed in total for all tasks to pass the rendezvous once?

A 8

B 6

C 12

D 4

💡 Hint

Consider that each task must wait for all others and signal all others.

Each of the 4 tasks must wait for the other 3 tasks and signal the other 3 tasks. Each wait and signal is a semaphore take or give. So total operations = 4 tasks * 3 waits + 4 tasks * 3 signals = 24 operations. But since each semaphore operation is counted once per pair, total unique operations are 12 (each pair has 2 operations).

Practice

1. What is the main purpose of the Rendezvous (sync) pattern in FreeRTOS?

easy

A. To synchronize two tasks so they wait for each other before proceeding

B. To create multiple independent tasks running without coordination

C. To prioritize one task over another permanently

D. To allocate memory dynamically for tasks

Solution

1. Step 1: Understand the Rendezvous pattern concept

   The Rendezvous pattern is designed to synchronize two tasks so that each waits for the other to reach a certain point before continuing.

2. Step 2: Identify the purpose in FreeRTOS context

   In FreeRTOS, this synchronization is often done using semaphores to signal readiness and wait for the other task.

3. Final Answer:

   To synchronize two tasks so they wait for each other before proceeding -> Option A

4. Quick Check:

   Rendezvous = Synchronize tasks [OK]

Hint: Rendezvous means tasks meet and wait for each other [OK]

Common Mistakes:

• Thinking it creates independent tasks without coordination
• Confusing with task prioritization
• Assuming it manages memory allocation

2. Which FreeRTOS primitive is typically used to implement the Rendezvous pattern?

easy

A. Mutex

B. Queue

C. Semaphore

D. Event Group

Solution

1. Step 1: Recall synchronization primitives in FreeRTOS

   FreeRTOS provides mutexes, semaphores, queues, and event groups for task synchronization and communication.

2. Step 2: Identify which primitive signals readiness and waits

   The Rendezvous pattern requires signaling and waiting between two tasks, which is best done using semaphores.

3. Final Answer:

   Semaphore -> Option C

4. Quick Check:

   Rendezvous uses semaphores [OK]

Hint: Semaphores signal and wait between tasks [OK]

Common Mistakes:

• Choosing mutex which is for mutual exclusion, not sync
• Confusing queues with direct signaling
• Using event groups which are for multiple event flags

3. Consider two tasks using binary semaphores for Rendezvous. Task A signals semaphore S1 and waits on S2. Task B signals S2 and waits on S1. What happens if Task A runs first and signals S1 before Task B waits on it?

medium

A. Both tasks will run without blocking

B. Task B will block indefinitely waiting on S1

C. Task A will block indefinitely waiting on S2

D. Task B will unblock immediately when it waits on S1

Solution

1. Step 1: Understand semaphore signaling and waiting

   If Task A signals semaphore S1 before Task B waits on it, the semaphore count becomes available.

2. Step 2: Analyze Task B's wait on S1

   When Task B waits on S1, it finds the semaphore already signaled and unblocks immediately without waiting.

3. Final Answer:

   Task B will unblock immediately when it waits on S1 -> Option D

4. Quick Check:

   Signaled semaphore unblocks waiting task immediately [OK]

Hint: Semaphore signals persist until taken by waiting task [OK]

Common Mistakes:

• Assuming tasks must wait even if semaphore is signaled
• Thinking Task A blocks waiting on S2 first
• Believing both tasks run without blocking always

4. Given this snippet for Rendezvous synchronization, what is the error?

void TaskA(void *pvParameters) {
  xSemaphoreGive(SemA);
  xSemaphoreTake(SemB, portMAX_DELAY);
  // Continue...
}

void TaskB(void *pvParameters) {
  xSemaphoreTake(SemA, portMAX_DELAY);
  xSemaphoreGive(SemB);
  // Continue...
}

medium

A. Tasks should not use semaphores for synchronization

B. Semaphores SemA and SemB are not created before use

C. xSemaphoreGive should be called after xSemaphoreTake in TaskA

D. portMAX_DELAY is invalid for xSemaphoreTake

Solution

1. Step 1: Check semaphore initialization

   Before using semaphores, they must be created with xSemaphoreCreateBinary or similar functions.

2. Step 2: Identify missing creation

   The code snippet does not show creation of SemA and SemB, which will cause runtime errors or undefined behavior.

3. Final Answer:

   Semaphores SemA and SemB are not created before use -> Option B

4. Quick Check:

   Semaphores must be created before giving or taking [OK]

Hint: Always create semaphores before using them [OK]

Common Mistakes:

• Thinking order of give/take is wrong here
• Believing semaphores are not for synchronization
• Misunderstanding portMAX_DELAY usage

5. You want two tasks to synchronize at multiple points using the Rendezvous pattern. Which approach ensures no deadlock if one task signals twice before the other waits?

hard

A. Use counting semaphores instead of binary semaphores

B. Use mutexes to lock and unlock tasks

C. Use queues to send messages instead of semaphores

D. Use event groups with a single bit flag

Solution

1. Step 1: Understand semaphore types and their behavior

   Binary semaphores can only hold one signal at a time, so signaling twice before waiting can cause lost signals and deadlock.

2. Step 2: Identify solution to handle multiple signals

   Counting semaphores can hold multiple signals, allowing tasks to signal multiple times without losing signals, preventing deadlock.

3. Final Answer:

   Use counting semaphores instead of binary semaphores -> Option A

4. Quick Check:

   Counting semaphores handle multiple signals safely [OK]

Hint: Counting semaphores count signals, preventing lost sync [OK]

Common Mistakes:

• Using mutexes which do not count signals
• Using queues which add complexity
• Using event groups with single bits only