Critical section with taskENTER_CRITICAL in FreeRTOS - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

Output of code using taskENTER_CRITICAL and taskEXIT_CRITICAL

What is the output of the following FreeRTOS code snippet that uses taskENTER_CRITICAL() and taskEXIT_CRITICAL()?

FreeRTOS

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

volatile int shared_counter = 0;

void increment_counter() {
    taskENTER_CRITICAL();
    shared_counter++;
    taskEXIT_CRITICAL();
}

int main() {
    increment_counter();
    increment_counter();
    printf("%d\n", shared_counter);
    return 0;
}

A 1

B 0

C 2

D Compilation error

💡 Hint

Think about what taskENTER_CRITICAL() and taskEXIT_CRITICAL() do to the shared variable.

The taskENTER_CRITICAL() disables interrupts to protect the critical section, so the increment operation on shared_counter is safe and not interrupted. Calling increment_counter() twice increases the counter from 0 to 2.

🧠 Conceptual

intermediate

Purpose of taskENTER_CRITICAL in FreeRTOS

What is the main purpose of using taskENTER_CRITICAL() in FreeRTOS?

A To disable task switching and interrupts to protect a critical section

B To start a new task immediately

C To send a message to a queue

D To allocate memory dynamically

💡 Hint

Think about what needs to be prevented during a critical section.

taskENTER_CRITICAL() disables interrupts and task switching to ensure that the code inside the critical section runs without interruption, preventing race conditions.

🔧 Debug

advanced

Identify the error in critical section usage

Consider the following code snippet. What error will occur when running this code?

FreeRTOS

void update_shared() {
    taskENTER_CRITICAL();
    shared_var++;
    // Missing taskEXIT_CRITICAL();
}

int main() {
    update_shared();
    return 0;
}

A The program will deadlock or freeze due to interrupts never being re-enabled

B The shared_var will not increment

C Compilation error due to missing taskEXIT_CRITICAL()

D No error, program runs normally

💡 Hint

What happens if interrupts stay disabled forever?

Because taskEXIT_CRITICAL() is missing, interrupts remain disabled, causing the system to freeze or deadlock as no interrupts can occur.

📝 Syntax

advanced

Syntax error in critical section usage

Which option contains a syntax error when using taskENTER_CRITICAL() and taskEXIT_CRITICAL()?

FreeRTOS

void func() {
    taskENTER_CRITICAL()
    shared_var++;
    taskEXIT_CRITICAL();
}

A Missing parentheses in taskEXIT_CRITICAL call

B Missing semicolon after taskENTER_CRITICAL() call

C Using curly braces instead of parentheses in taskENTER_CRITICAL

D No syntax error

💡 Hint

Check each line for missing punctuation.

taskENTER_CRITICAL() is a macro or function call and must end with a semicolon. Missing it causes a syntax error.

🚀 Application

expert

Effect of nested taskENTER_CRITICAL calls

What is the value of shared_counter after running the following code?

FreeRTOS

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

volatile int shared_counter = 0;

void nested_critical() {
    taskENTER_CRITICAL();
    shared_counter++;
    taskENTER_CRITICAL();
    shared_counter++;
    taskEXIT_CRITICAL();
    taskEXIT_CRITICAL();
}

int main() {
    nested_critical();
    printf("%d\n", shared_counter);
    return 0;
}

A 0

B 1

C Runtime error due to nested critical sections

D 2

💡 Hint

Consider how nested critical sections behave in FreeRTOS.

FreeRTOS supports nesting of critical sections. Each taskENTER_CRITICAL() increments a nesting count and disables interrupts only once. The shared_counter increments twice safely, so the final value is 2.

Practice

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

easy

A. To allocate memory dynamically

B. To disable interrupts and protect shared data during a critical section

C. To start a new task in the scheduler

D. To send a message to a queue

Solution

1. Step 1: Understand what taskENTER_CRITICAL() does

   This function disables interrupts to prevent context switches and protect shared resources.

2. Step 2: Identify the purpose in multitasking

   Disabling interrupts ensures that the critical section code runs without interruption, avoiding data corruption.

3. Final Answer:

   To disable interrupts and protect shared data during a critical section -> Option B

4. Quick Check:

   Critical section protection = disable interrupts [OK]

Hint: Remember: critical section means no interrupts [OK]

Common Mistakes:

• Confusing task creation with critical section
• Thinking it allocates memory
• Assuming it sends messages

2. Which of the following is the correct syntax to start a critical section in FreeRTOS?

easy

A. enter_critical_section();

B. taskENTER_CRITICAL;

C. taskENTER_CRITICAL();

D. task_enter_critical();

Solution

1. Step 1: Recall the exact function name and syntax

   The correct FreeRTOS API function to enter a critical section is taskENTER_CRITICAL() with parentheses.

2. Step 2: Check the options for correct spelling and syntax

   Only taskENTER_CRITICAL(); uses the exact function name with parentheses, which is required to call the function.

3. Final Answer:

   taskENTER_CRITICAL(); -> Option C

4. Quick Check:

   Function call syntax = parentheses needed [OK]

Hint: Function calls always need parentheses () [OK]

Common Mistakes:

• Omitting parentheses when calling functions
• Using incorrect function names
• Confusing with similar sounding functions

3. Consider the following FreeRTOS code snippet:

int sharedCounter = 0;

void incrementCounter() {
    taskENTER_CRITICAL();
    sharedCounter++;
    taskEXIT_CRITICAL();
}

incrementCounter();
printf("%d", sharedCounter);

What will be the output after running this code once?

medium

A. 1

B. 0

C. Compilation error

D. Undefined behavior

Solution

1. Step 1: Analyze the increment inside the critical section

   The function increments sharedCounter by 1 while interrupts are disabled, ensuring safe update.

2. Step 2: Check the output after one call

   After calling incrementCounter() once, sharedCounter becomes 1, so printing it outputs 1.

3. Final Answer:

   1 -> Option A

4. Quick Check:

   Increment once = 1 [OK]

Hint: Increment inside critical section updates safely [OK]

Common Mistakes:

• Assuming no increment due to critical section
• Thinking code won't compile
• Confusing output with initial value

4. Identify the error in this FreeRTOS critical section code:

void updateData() {
    taskENTER_CRITICAL();
    sharedData = 42;
    // Missing taskEXIT_CRITICAL();
}

medium

A. Missing taskEXIT_CRITICAL() causes interrupts to stay disabled

B. sharedData must be declared volatile

C. Using taskENTER_CRITICAL() inside a function is invalid

D. No error, code is correct

Solution

1. Step 1: Check for matching critical section calls

   The code calls taskENTER_CRITICAL() but does not call taskEXIT_CRITICAL(), so interrupts remain disabled.

2. Step 2: Understand consequences of missing exit

   Interrupts staying disabled can freeze the system or cause missed interrupts, which is a serious error.

3. Final Answer:

   Missing taskEXIT_CRITICAL() causes interrupts to stay disabled -> Option A

4. Quick Check:

   Always pair enter and exit critical [OK]

Hint: Always match enter and exit critical calls [OK]

Common Mistakes:

• Forgetting to call taskEXIT_CRITICAL()
• Thinking enter critical is invalid in functions
• Assuming volatile fixes missing exit

5. You have two tasks incrementing a shared variable counter. To avoid race conditions, you use a critical section:

void increment() {
    taskENTER_CRITICAL();
    counter++;
    taskEXIT_CRITICAL();
}

However, the system becomes unresponsive when interrupts are disabled for too long. What is the best way to improve this?

hard

A. Remove the critical section to improve responsiveness

B. Use a busy-wait loop inside the critical section

C. Disable interrupts globally for the entire task duration

D. Keep the critical section as short as possible, only around the increment

Solution

1. Step 1: Understand impact of long critical sections

   Disabling interrupts for too long blocks other important system activities, causing unresponsiveness.

2. Step 2: Optimize critical section length

   Keeping the critical section short, only around the shared variable update, minimizes interrupt blocking and improves responsiveness.

3. Final Answer:

   Keep the critical section as short as possible, only around the increment -> Option D

4. Quick Check:

   Short critical section = better responsiveness [OK]

Hint: Shorten critical sections to keep system responsive [OK]

Common Mistakes:

• Removing critical section causing race conditions
• Disabling interrupts too long
• Using busy-wait inside critical section