Why semaphores are needed in FreeRTOS - Visual Breakdown

Concept Flow - Why semaphores are needed

Task 1 wants resource

↓

Check if resource free?

No→Wait (block)

Yes↓

Take resource (lock)

↓

Use resource

↓

Release resource (unlock)

↓

Other waiting tasks notified

↓

Next task takes resource

Tasks check if a resource is free; if not, they wait. When free, a task locks it, uses it, then unlocks it, allowing others to proceed.

Execution Sample

FreeRTOS

if (xSemaphoreTake(xSemaphore, portMAX_DELAY) == pdTRUE) {
    // Access shared resource
    xSemaphoreGive(xSemaphore);
}

Task tries to take semaphore to access resource; if successful, uses resource then releases semaphore.

Execution Table

Step	Task	Semaphore State	Action	Result
1	Task A	Free	xSemaphoreTake() called	Semaphore taken, Task A proceeds
2	Task B	Taken by Task A	xSemaphoreTake() called	Task B blocks, waits
3	Task A	Taken by Task A	Uses resource	Resource used
4	Task A	Taken by Task A	xSemaphoreGive() called	Semaphore released
5	Task B	Free	Unblocked, xSemaphoreTake() succeeds	Task B takes semaphore
6	Task B	Taken by Task B	Uses resource	Resource used
7	Task B	Taken by Task B	xSemaphoreGive() called	Semaphore released
8	-	Free	-	All tasks done, semaphore free

💡 All tasks have accessed the resource safely; semaphore ensures exclusive access.

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 4	After Step 5	After Step 7	Final
Semaphore State	Free	Taken by Task A	Taken by Task A	Free	Taken by Task B	Free	Free
Task A Status	Waiting	Running (has semaphore)	Running (using resource)	Done	Done	Done	Done
Task B Status	Waiting	Waiting	Waiting (blocked)	Waiting (unblocked)	Running (has semaphore)	Done	Done

Key Moments - 3 Insights

Why does Task B wait when Task A has the semaphore?

Because the semaphore is taken by Task A (see execution_table step 2), Task B must wait to avoid both using the resource at the same time.

What happens when Task A releases the semaphore?

When Task A calls xSemaphoreGive (step 4), the semaphore becomes free, unblocking Task B so it can take the semaphore and use the resource (step 5).

Why is it important to release the semaphore after using the resource?

Releasing the semaphore (step 4 and 7) allows other tasks waiting for the resource to proceed, preventing deadlock and ensuring fair access.

Visual Quiz - 3 Questions

Look at the execution_table at step 2, what is the state of the semaphore?

A Taken by Task A

B Free

C Taken by Task B

D Unknown

💡 Hint

Check the 'Semaphore State' column at step 2 in the execution_table.

At which step does Task B successfully take the semaphore?

A Step 1

B Step 5

C Step 4

D Step 7

💡 Hint

Look for when Task B changes from waiting to running with semaphore in the execution_table.

If Task A never calls xSemaphoreGive, what happens to Task B?

A Task B proceeds immediately

B Task B takes semaphore anyway

C Task B waits forever (blocks)

D Task B crashes

💡 Hint

Refer to the blocking behavior shown in execution_table step 2 and the importance of releasing semaphore in step 4.

Concept Snapshot

Semaphore controls access to shared resources.
Tasks take (lock) semaphore before use.
If taken, other tasks wait (block).
Task releases (gives) semaphore after use.
Ensures only one task uses resource at a time.
Prevents conflicts and data corruption.

Full Transcript

Semaphores are needed in FreeRTOS to manage access to shared resources. When a task wants to use a resource, it tries to take the semaphore. If the semaphore is free, the task takes it and proceeds. If not, the task waits (blocks) until the semaphore is released. After using the resource, the task releases the semaphore, allowing other waiting tasks to take it. This process prevents multiple tasks from using the resource simultaneously, avoiding conflicts and ensuring safe operation.

Practice

1. Why are semaphores needed in FreeRTOS when multiple tasks share a resource?

easy

A. To prevent tasks from accessing the resource at the same time and causing errors

B. To speed up the execution of all tasks simultaneously

C. To allow tasks to ignore each other and run independently

D. To increase the memory usage of the system

Solution

1. Step 1: Understand resource sharing in multitasking

   When multiple tasks share a resource, simultaneous access can cause data corruption or crashes.

2. Step 2: Role of semaphores in synchronization

   Semaphores act as signals to control access, allowing only one task at a time to use the resource safely.

3. Final Answer:

   To prevent tasks from accessing the resource at the same time and causing errors -> Option A

4. Quick Check:

   Semaphores prevent simultaneous access = A [OK]

Hint: Semaphores stop tasks from clashing over shared resources [OK]

Common Mistakes:

• Thinking semaphores speed up all tasks
• Believing tasks run independently without coordination
• Assuming semaphores increase memory usage

2. Which of the following is the correct way to create a binary semaphore in FreeRTOS?

easy

A. xSemaphoreCreateBinary();

B. SemaphoreCreateBinary();

C. createBinarySemaphore();

D. newSemaphoreBinary();

Solution

1. Step 1: Recall FreeRTOS semaphore creation functions

   FreeRTOS provides the function xSemaphoreCreateBinary() to create a binary semaphore.

2. Step 2: Verify syntax correctness

   The function name must start with 'x' and match the exact FreeRTOS API naming conventions.

3. Final Answer:

   xSemaphoreCreateBinary(); -> Option A

4. Quick Check:

   Correct FreeRTOS binary semaphore function = D [OK]

Hint: FreeRTOS functions start with 'x' for handles [OK]

Common Mistakes:

• Using incorrect function names without 'x' prefix
• Confusing with other RTOS APIs
• Adding extra words to function names

3. Consider this FreeRTOS code snippet:

SemaphoreHandle_t sem = xSemaphoreCreateBinary();
xSemaphoreGive(sem);
if(xSemaphoreTake(sem, 0) == pdTRUE) {
    printf("Access granted\n");
} else {
    printf("Access denied\n");
}

What will be the output?

medium

A. Access denied

B. Access granted

C. Compilation error

D. No output

Solution

1. Step 1: Understand semaphore creation and initial state

   The binary semaphore is created and then given once, so it is available (count = 1).

2. Step 2: Check the take operation with zero wait

   The xSemaphoreTake tries to take the semaphore immediately (timeout 0). Since it was given before, it succeeds.

3. Final Answer:

   Access granted -> Option B

4. Quick Check:

   Semaphore given then taken immediately = Access granted [OK]

Hint: Semaphore given before take means immediate success [OK]

Common Mistakes:

• Assuming zero timeout means failure
• Forgetting to give semaphore before take
• Confusing binary semaphore initial state

4. This FreeRTOS code snippet tries to protect a shared resource:

SemaphoreHandle_t sem = xSemaphoreCreateBinary();
// Task A
xSemaphoreTake(sem, portMAX_DELAY);
// Access resource
xSemaphoreGive(sem);
// Task B
xSemaphoreTake(sem, portMAX_DELAY);
// Access resource
xSemaphoreGive(sem);

What is the main problem here?

medium

A. The semaphore is created as binary but used as counting

B. The semaphore is given twice causing overflow

C. The semaphore is never given initially, so tasks block forever

D. The tasks do not take the semaphore before accessing resource

Solution

1. Step 1: Check semaphore initial state after creation

   Binary semaphore created with xSemaphoreCreateBinary() starts empty (not given).

2. Step 2: Analyze task behavior on take

   Task A tries to take semaphore but it was never given, so it blocks forever. Same for Task B.

3. Final Answer:

   The semaphore is never given initially, so tasks block forever -> Option C

4. Quick Check:

   Binary semaphore must be given once before take = C [OK]

Hint: Binary semaphore must be given once before tasks take it [OK]

Common Mistakes:

• Assuming semaphore is given automatically on creation
• Thinking multiple gives cause overflow
• Ignoring semaphore take before resource access

5. You have two tasks sharing a sensor. Task 1 reads data and Task 2 processes it. Without semaphores, data corruption occurs. How should you use semaphores to fix this?

hard

A. Use a counting semaphore with count 0 to block both tasks

B. Use a mutex but never give it back after taking

C. Use no semaphore and rely on task priorities to avoid conflicts

D. Use a binary semaphore to let only one task access the sensor at a time

Solution

1. Step 1: Identify the problem of simultaneous access

   Both tasks accessing the sensor at the same time cause data corruption.

2. Step 2: Choose semaphore type and usage

   A binary semaphore ensures only one task accesses the sensor at a time, preventing conflicts.

3. Final Answer:

   Use a binary semaphore to let only one task access the sensor at a time -> Option D

4. Quick Check:

   Binary semaphore controls exclusive access = B [OK]

Hint: Binary semaphore allows one task access at a time [OK]

Common Mistakes:

• Using counting semaphore incorrectly with zero count
• Ignoring semaphore and trusting priorities alone
• Not releasing mutex causing deadlock