xSemaphoreGive() and xSemaphoreTake() in FreeRTOS - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to take a semaphore before accessing a shared resource.

FreeRTOS

if (xSemaphoreTake(sem, [1]) == pdTRUE) {
    // Access shared resource
    xSemaphoreGive(sem);
}

Drag options to blanks, or click blank then click option'

AportMAX_DELAY

B100

CpdFALSE

D0

Attempts:

3 left

💡 Hint

Common Mistakes

Using 0 causes the task to not wait and fail immediately if semaphore is not available.

Using pdFALSE is incorrect as it is not a valid wait time.

Using portMAX_DELAY makes the task wait indefinitely until the semaphore is available.

2fill in blank

medium

Complete the code to give the semaphore after finishing the critical section.

FreeRTOS

void task_function(void *params) {
    if (xSemaphoreTake(sem, portMAX_DELAY) == pdTRUE) {
        // Critical section code
        [1](sem);
    }
}

Drag options to blanks, or click blank then click option'

AvTaskDelay

BxSemaphoreGive

CxSemaphoreTake

DxQueueSend

Attempts:

3 left

💡 Hint

Common Mistakes

Calling xSemaphoreTake again instead of giving the semaphore.

Using unrelated functions like vTaskDelay or xQueueSend.

After finishing the critical section, xSemaphoreGive() releases the semaphore so other tasks can take it.

3fill in blank

hard

Fix the error in the code to correctly take the semaphore with a timeout of 50 ticks.

FreeRTOS

if (xSemaphoreTake(sem, [1]) == pdTRUE) {
    // Critical section
    xSemaphoreGive(sem);
}

Drag options to blanks, or click blank then click option'

A50

BpdFALSE

CportMAX_DELAY

D-1

Attempts:

3 left

💡 Hint

Common Mistakes

Using pdFALSE which means no wait.

Using negative values which are invalid.

The timeout parameter should be the number of ticks to wait, here 50 ticks.

4fill in blank

hard

Fill both blanks to check if the semaphore was successfully taken within 10 ticks.

FreeRTOS

if (xSemaphoreTake(sem, [1]) == [2]) {
    // Semaphore taken successfully
}

Drag options to blanks, or click blank then click option'

A10

BpdTRUE

CpdFALSE

DportMAX_DELAY

Attempts:

3 left

💡 Hint

Common Mistakes

Using pdFALSE as success value.

Using portMAX_DELAY instead of 10 ticks.

The code waits 10 ticks and checks if the semaphore was taken successfully (pdTRUE).

5fill in blank

hard

Fill all three blanks to return the result of giving the semaphore only if the task took it successfully, else pdFALSE.

FreeRTOS

BaseType_t result = (xSemaphoreTake(sem, [1]) == [2]) ? xSemaphoreGive(sem) : [3];

Drag options to blanks, or click blank then click option'

AportMAX_DELAY

BpdTRUE

CpdFALSE

D0

Attempts:

3 left

💡 Hint

Common Mistakes

Using 0 or other values for wait time that cause immediate failure.

Using pdFALSE as success check.

Using 0 instead of pdFALSE as fallback.

The code waits indefinitely to take the semaphore, checks for success (pdTRUE), gives the semaphore if successful, else pdFALSE.

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