Rendezvous (sync) pattern in FreeRTOS

Introduction

The Rendezvous pattern helps two tasks meet at the same point and wait for each other before continuing. It makes sure both tasks are ready before moving on.

When two tasks need to exchange data safely at the same time.

When one task must wait for another to reach a certain point before proceeding.

When coordinating start or end of operations between tasks.

When synchronizing tasks that depend on each other's state.

When you want to avoid race conditions by making tasks wait for each other.

Syntax

FreeRTOS

/* Use two binary semaphores for synchronization */
SemaphoreHandle_t semTask1, semTask2;

void Task1(void *params) {
    // Do some work
    xSemaphoreGive(semTask1); // Signal Task1 is ready
    xSemaphoreTake(semTask2, portMAX_DELAY); // Wait for Task2
    // Continue after rendezvous
}

void Task2(void *params) {
    // Do some work
    xSemaphoreGive(semTask2); // Signal Task2 is ready
    xSemaphoreTake(semTask1, portMAX_DELAY); // Wait for Task1
    // Continue after rendezvous
}

Two binary semaphores are used to signal readiness between tasks.

Each task signals it is ready and waits for the other task's signal.

Examples

This example shows two tasks signaling each other using binary semaphores to synchronize at a rendezvous point.

FreeRTOS

SemaphoreHandle_t semTask1 = xSemaphoreCreateBinary();
SemaphoreHandle_t semTask2 = xSemaphoreCreateBinary();

void Task1(void *params) {
    // Work before rendezvous
    xSemaphoreGive(semTask1);
    xSemaphoreTake(semTask2, portMAX_DELAY);
    // Work after rendezvous
}

void Task2(void *params) {
    // Work before rendezvous
    xSemaphoreGive(semTask2);
    xSemaphoreTake(semTask1, portMAX_DELAY);
    // Work after rendezvous
}

Counting semaphores can be used if multiple rendezvous points are needed.

FreeRTOS

/* Using counting semaphores for multiple rendezvous */
SemaphoreHandle_t semTask1 = xSemaphoreCreateCounting(1, 0);
SemaphoreHandle_t semTask2 = xSemaphoreCreateCounting(1, 0);

void Task1(void *params) {
    xSemaphoreGive(semTask1);
    xSemaphoreTake(semTask2, portMAX_DELAY);
}

void Task2(void *params) {
    xSemaphoreGive(semTask2);
    xSemaphoreTake(semTask1, portMAX_DELAY);
}

Sample Program

This program creates two tasks that do some work, then wait for each other using semaphores. They print messages before and after the rendezvous to show synchronization.

FreeRTOS

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

SemaphoreHandle_t semTask1, semTask2;

void Task1(void *params) {
    printf("Task1: Starting work before rendezvous\n");
    vTaskDelay(pdMS_TO_TICKS(1000)); // Simulate work
    printf("Task1: Ready, signaling Task2\n");
    xSemaphoreGive(semTask1);
    xSemaphoreTake(semTask2, portMAX_DELAY);
    printf("Task1: Rendezvous complete, continuing work\n");
    vTaskDelete(NULL);
}

void Task2(void *params) {
    printf("Task2: Starting work before rendezvous\n");
    vTaskDelay(pdMS_TO_TICKS(2000)); // Simulate longer work
    printf("Task2: Ready, signaling Task1\n");
    xSemaphoreGive(semTask2);
    xSemaphoreTake(semTask1, portMAX_DELAY);
    printf("Task2: Rendezvous complete, continuing work\n");
    vTaskDelete(NULL);
}

int main(void) {
    semTask1 = xSemaphoreCreateBinary();
    semTask2 = xSemaphoreCreateBinary();

    xTaskCreate(Task1, "Task1", 1000, NULL, 1, NULL);
    xTaskCreate(Task2, "Task2", 1000, NULL, 1, NULL);

    vTaskStartScheduler();

    for(;;);
    return 0;
}

Important Notes

Make sure semaphores are created before starting tasks.

Use portMAX_DELAY to wait indefinitely for the other task.

Rendezvous ensures both tasks reach the point before continuing.

Summary

The Rendezvous pattern uses semaphores to synchronize two tasks.

Each task signals readiness and waits for the other.

This avoids race conditions and coordinates task progress.

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