xSemaphoreGive() and xSemaphoreTake() in FreeRTOS - Step-by-Step Execution

Concept Flow - xSemaphoreGive() and xSemaphoreTake()

Task wants resource

↓

Call xSemaphoreTake()

↓

Is semaphore available?

No→Block task, wait

Yes↓

Task uses resource

↓

Call xSemaphoreGive()

↓

Semaphore released

↓

Unblock waiting task if any

↓

Next task takes semaphore or resource free

This flow shows how a task tries to take a semaphore to access a resource, waits if unavailable, and then gives it back to release.

Execution Sample

FreeRTOS

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

Task tries to take semaphore, waits forever if needed, accesses resource, then gives semaphore back.

Execution Table

Step	Action	Semaphore State Before	Semaphore State After	Task State	Notes
1	Task calls xSemaphoreTake()	Available	Taken	Running	Semaphore was free, task takes it
2	Task accesses resource	Taken	Taken	Running	Task uses resource exclusively
3	Task calls xSemaphoreGive()	Taken	Available	Running	Semaphore released, resource free
4	Another task calls xSemaphoreTake()	Available	Taken	Running	Semaphore taken by next task
5	Task calls xSemaphoreTake()	Taken	Taken	Blocked	Semaphore busy, task blocks waiting
6	First task calls xSemaphoreGive()	Taken	Available	Running	Semaphore released, unblocks waiting task
7	Blocked task unblocked and takes semaphore	Available	Taken	Running	Waiting task resumes and takes semaphore

💡 Execution stops when tasks finish or no more semaphore operations occur.

Variable Tracker

Variable	Start	After Step 1	After Step 3	After Step 5	After Step 6	Final
Semaphore State	Available	Taken	Available	Taken	Available	Taken
Task State	Idle	Running	Running	Blocked	Running	Running

Key Moments - 2 Insights

Why does the task block at step 5 when calling xSemaphoreTake()?

At step 5, the semaphore is already taken by another task (see 'Semaphore State Before' is 'Taken'), so the calling task must wait until it becomes available.

What happens when xSemaphoreGive() is called at step 6?

At step 6, the semaphore is released (state changes from 'Taken' to 'Available'), which unblocks any waiting tasks so they can take the semaphore next.

Visual Quiz - 3 Questions

Look at the execution table, what is the semaphore state after step 3?

A Blocked

B Taken

C Available

D Undefined

💡 Hint

Check the 'Semaphore State After' column for step 3 in the execution table.

At which step does a task become blocked waiting for the semaphore?

A Step 2

B Step 5

C Step 4

D Step 7

💡 Hint

Look at the 'Task State' column and find when it changes to 'Blocked'.

If the semaphore was never given back, what would happen to the task at step 7?

A It would remain blocked forever

B It would take the semaphore anyway

C It would skip taking the semaphore

D It would cause an error

💡 Hint

Refer to the 'Semaphore State' and 'Task State' in the execution table rows 5-7.

Concept Snapshot

xSemaphoreTake(semaphore, timeout) tries to take the semaphore.
If available, it returns immediately; else blocks or times out.
xSemaphoreGive(semaphore) releases the semaphore.
Used to protect shared resources between tasks.
Tasks block if semaphore is busy, unblocked when given back.

Full Transcript

This visual execution shows how FreeRTOS tasks use xSemaphoreTake() to request access to a shared resource by taking a semaphore. If the semaphore is available, the task takes it and proceeds to use the resource. If not, the task blocks and waits. When done, the task calls xSemaphoreGive() to release the semaphore, making it available for other tasks. The execution table traces each step, showing semaphore state changes and task states, including blocking and unblocking behavior. Key moments clarify why tasks block and how releasing the semaphore unblocks waiting tasks. The quiz tests understanding of semaphore states and task blocking during execution.

Practice

1. What is the main purpose of xSemaphoreTake() in FreeRTOS?

easy

A. To lock the semaphore and gain exclusive access to a resource

B. To unlock the semaphore and release the resource

C. To create a new semaphore

D. To delete an existing semaphore

Solution

1. Step 1: Understand the role of xSemaphoreTake()

   This function is used by a task to lock a semaphore, which means it tries to gain exclusive access to a shared resource.

2. Step 2: Differentiate from xSemaphoreGive()

   xSemaphoreGive() is used to release or unlock the semaphore, not to lock it.

3. Final Answer:

   To lock the semaphore and gain exclusive access to a resource -> Option A

4. Quick Check:

   xSemaphoreTake() locks = B [OK]

Hint: Take locks resource, Give unlocks it [OK]

Common Mistakes:

• Confusing take with give
• Thinking take creates semaphore
• Mixing up locking and unlocking

2. Which of the following is the correct syntax to take a semaphore named xSemaphore with a block time of 100 ticks?

easy

A. xSemaphoreTake(100, xSemaphore);

B. xSemaphoreTake(xSemaphore, 100);

C. xSemaphoreGive(xSemaphore, 100);

D. xSemaphoreGive(100, xSemaphore);

Solution

1. Step 1: Recall function signature of xSemaphoreTake()

   The correct syntax is xSemaphoreTake(SemaphoreHandle, BlockTimeTicks); where the first argument is the semaphore handle and second is the block time.

2. Step 2: Match the options with correct order

   xSemaphoreTake(xSemaphore, 100); matches the correct order: xSemaphoreTake(xSemaphore, 100);. Options B and D use xSemaphoreGive which is wrong here. xSemaphoreTake(100, xSemaphore); reverses the arguments.

3. Final Answer:

   xSemaphoreTake(xSemaphore, 100); -> Option B

4. Quick Check:

   Take(semaphore, time) = C [OK]

Hint: Take(semaphore, time) is correct order [OK]

Common Mistakes:

• Swapping arguments order
• Using xSemaphoreGive instead of xSemaphoreTake
• Passing block time as first argument

3. Consider the following code snippet:

if (xSemaphoreTake(xSemaphore, 10) == pdTRUE) {
    // Critical section
    xSemaphoreGive(xSemaphore);
    printf("Access granted\n");
} else {
    printf("Access denied\n");
}

What will be printed if the semaphore is already taken by another task and not given back within 10 ticks?

medium

A. Access granted

B. Runtime error

C. No output

D. Access denied

Solution

1. Step 1: Understand xSemaphoreTake() behavior with timeout

   If the semaphore is already taken and not released within the 10 tick block time, xSemaphoreTake() returns pdFALSE.

2. Step 2: Analyze the if condition and output

   Since xSemaphoreTake() returns pdFALSE, the else branch executes, printing "Access denied".

3. Final Answer:

   Access denied -> Option D

4. Quick Check:

   Semaphore busy + timeout = Access denied [OK]

Hint: If take fails within timeout, else branch runs [OK]

Common Mistakes:

• Assuming take always succeeds
• Ignoring block time effect
• Expecting 'Access granted' always

4. Identify the error in this code snippet:

if (xSemaphoreGive(xSemaphore) == pdTRUE) {
    // Critical section
    xSemaphoreTake(xSemaphore, portMAX_DELAY);
}

medium

A. xSemaphoreGive should not be called before taking the semaphore

B. xSemaphoreTake should not use portMAX_DELAY

C. xSemaphoreGive returns void, so comparison is invalid

D. No error, code is correct

Solution

1. Step 1: Understand correct semaphore usage order

   A task must first take (lock) the semaphore before giving (unlocking) it. Calling xSemaphoreGive() before xSemaphoreTake() is incorrect.

2. Step 2: Check function return types and usage

   xSemaphoreGive() returns BaseType_t, so comparing to pdTRUE is valid. Using portMAX_DELAY in xSemaphoreTake() is allowed to wait indefinitely.

3. Final Answer:

   xSemaphoreGive should not be called before taking the semaphore -> Option A

4. Quick Check:

   Give before Take is wrong order [OK]

Hint: Always take before give [OK]

Common Mistakes:

• Calling give before take
• Misunderstanding return values
• Thinking portMAX_DELAY is invalid

5. You have two tasks sharing a resource protected by a binary semaphore xSemaphore. Task A takes the semaphore, performs work, then gives it back. Task B tries to take the semaphore with a 50 tick timeout. If Task A forgets to give the semaphore back, what will happen to Task B?

hard

A. Task B will block forever waiting for the semaphore

B. Task B will immediately take the semaphore without blocking

C. Task B will block for 50 ticks, then continue without the resource

D. Task B will cause a system crash

Solution

1. Step 1: Understand semaphore blocking with timeout

   Task B calls xSemaphoreTake() with a 50 tick timeout, so it will wait up to 50 ticks for the semaphore to become available.

2. Step 2: Analyze effect of Task A not giving semaphore back

   If Task A never gives the semaphore back, Task B will wait the full 50 ticks, then xSemaphoreTake() returns pdFALSE, so Task B continues without the resource.

3. Final Answer:

   Task B will block for 50 ticks, then continue without the resource -> Option C

4. Quick Check:

   Timeout reached without give = block then continue [OK]

Hint: Timeout means wait then fail, not infinite block [OK]

Common Mistakes:

• Assuming infinite block without timeout
• Thinking semaphore is taken immediately
• Believing system crashes on semaphore misuse