📖 Scenario: You are building a simple FreeRTOS program where two tasks must wait for each other at a synchronization point before continuing. This is called the Rendezvous pattern.Imagine two friends arriving at a meeting point. Neither leaves until both have arrived. This ensures they start together.
🎯 Goal: Create two FreeRTOS tasks that synchronize using a binary semaphore to implement the Rendezvous pattern. Each task waits for the other to reach the sync point before proceeding.
📋 What You'll Learn
Create two tasks named Task1 and Task2
Create a binary semaphore called syncSemaphore
Each task must wait for the other by taking and giving the semaphore
Print messages showing when each task reaches and leaves the rendezvous point
💡 Why This Matters
🌍 Real World
The Rendezvous pattern is useful in embedded systems where multiple tasks must wait for each other before continuing, such as coordinating sensor readings or communication.
💼 Career
Understanding task synchronization with semaphores is essential for embedded software engineers working with real-time operating systems like FreeRTOS.
Progress0 / 4 steps
1
Create the binary semaphore
Create a binary semaphore called syncSemaphore using xSemaphoreCreateBinary() and give it initially using xSemaphoreGive(syncSemaphore).
FreeRTOS
Hint
Use xSemaphoreCreateBinary() to create the semaphore and xSemaphoreGive() to set it initially.
2
Create Task1 and Task2 functions
Create two task functions named Task1 and Task2 with the signature void Task1(void *pvParameters) and void Task2(void *pvParameters). Inside each, add an infinite loop for (;;).
FreeRTOS
Hint
Define two functions with the correct signature and add an infinite loop inside each.
3
Implement the Rendezvous synchronization in tasks
Inside the infinite loop of Task1 and Task2, add code to print "Task1 reached rendezvous" or "Task2 reached rendezvous" respectively, then take the semaphore using xSemaphoreTake(syncSemaphore, portMAX_DELAY), then give the semaphore back using xSemaphoreGive(syncSemaphore). This will synchronize the tasks.
FreeRTOS
Hint
Use printf to show the message, then use xSemaphoreTake and xSemaphoreGive to synchronize.
4
Create tasks and start the scheduler
In main(), create the two tasks Task1 and Task2 using xTaskCreate() with priority 1 and stack size 100, then start the scheduler with vTaskStartScheduler(). This will run the tasks and show the rendezvous synchronization messages.
FreeRTOS
Hint
Use xTaskCreate() to create each task with the given parameters, then call vTaskStartScheduler() to start running.
Practice
(1/5)
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
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.
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.
Final Answer:
To synchronize two tasks so they wait for each other before proceeding -> Option A
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
Step 1: Recall synchronization primitives in FreeRTOS
FreeRTOS provides mutexes, semaphores, queues, and event groups for task synchronization and communication.
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.
Final Answer:
Semaphore -> Option C
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
Step 1: Understand semaphore signaling and waiting
If Task A signals semaphore S1 before Task B waits on it, the semaphore count becomes available.
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.
Final Answer:
Task B will unblock immediately when it waits on S1 -> Option D
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
Step 1: Check semaphore initialization
Before using semaphores, they must be created with xSemaphoreCreateBinary or similar functions.
Step 2: Identify missing creation
The code snippet does not show creation of SemA and SemB, which will cause runtime errors or undefined behavior.
Final Answer:
Semaphores SemA and SemB are not created before use -> Option B
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
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.
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.
Final Answer:
Use counting semaphores instead of binary semaphores -> Option A