Critical section with taskENTER_CRITICAL in FreeRTOS - Step-by-Step Execution

Concept Flow - Critical section with taskENTER_CRITICAL

Start Task

↓

Call taskENTER_CRITICAL

↓

Critical Section: Access shared resource

↓

Call taskEXIT_CRITICAL

↓

Continue Task Execution

↓

End Task or Loop

The task enters a critical section to safely access shared resources by disabling interrupts, then exits to restore normal operation.

Execution Sample

FreeRTOS

taskENTER_CRITICAL();
shared_counter++;
taskEXIT_CRITICAL();

This code safely increments a shared counter by disabling interrupts during the update.

Execution Table

Step	Action	Interrupts Enabled?	shared_counter Value	Notes
1	Start task	Yes	0	Initial state, interrupts enabled
2	Call taskENTER_CRITICAL()	No	0	Interrupts disabled, entering critical section
3	Increment shared_counter	No	1	Safe update without interruption
4	Call taskEXIT_CRITICAL()	Yes	1	Interrupts restored, leaving critical section
5	Continue task	Yes	1	Normal operation resumes

💡 Task finishes critical section and restores interrupts to allow other tasks and ISRs.

Variable Tracker

Variable	Start	After step 3	After step 5
shared_counter	0	1	1
Interrupts Enabled	Yes	No	Yes

Key Moments - 3 Insights

Why do interrupts get disabled when entering the critical section?

Interrupts are disabled at step 2 to prevent other tasks or ISRs from interrupting and causing race conditions while accessing shared resources.

What happens if taskEXIT_CRITICAL() is not called?

If taskEXIT_CRITICAL() is not called (step 4), interrupts remain disabled, which can block other tasks and ISRs, causing system issues.

Can other tasks run during the critical section?

No, during the critical section (steps 2-4), interrupts are disabled, so other tasks or ISRs cannot preempt this task.

Visual Quiz - 3 Questions

Look at the execution table, at which step are interrupts disabled?

A Step 4

B Step 1

C Step 2

D Step 5

💡 Hint

Check the 'Interrupts Enabled?' column in the execution table.

According to the variable tracker, what is the value of shared_counter after step 3?

A 1

B 0

C 2

D Undefined

💡 Hint

Look at the 'shared_counter' row under 'After step 3' in the variable tracker.

If taskEXIT_CRITICAL() is skipped, what happens to interrupts?

A They remain enabled

B They get disabled permanently

C They toggle on and off

D They are enabled only during shared_counter increment

💡 Hint

Refer to the key moment about what happens if taskEXIT_CRITICAL() is not called.

Concept Snapshot

taskENTER_CRITICAL() disables interrupts to protect shared resources.
Critical section code runs safely without interruption.
taskEXIT_CRITICAL() restores interrupts.
Always pair enter and exit calls to avoid system lock.
Use for short, quick critical sections only.

Full Transcript

This example shows how a FreeRTOS task uses taskENTER_CRITICAL() to disable interrupts before accessing a shared variable, ensuring no other task or interrupt can interfere. The shared_counter is safely incremented while interrupts are disabled. Then taskEXIT_CRITICAL() is called to re-enable interrupts, allowing normal system operation to continue. The execution table traces each step, showing when interrupts are disabled and the shared_counter value changes. The variable tracker highlights the state changes of interrupts and the counter. Key moments clarify why disabling interrupts is necessary and the importance of restoring them. The visual quiz tests understanding of these steps and their effects. This pattern prevents race conditions in multitasking environments by protecting critical sections with interrupt control.

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