xSemaphoreCreateMutex() function in FreeRTOS - Step-by-Step Execution

Concept Flow - xSemaphoreCreateMutex() function

Call xSemaphoreCreateMutex()

↓

Create a mutex semaphore

↓

Return handle to mutex

↓

Use mutex to protect shared resource

↓

Give mutex when done

↓

Other tasks can take mutex

The function creates a mutex semaphore and returns a handle to it, which tasks use to safely access shared resources.

Execution Sample

FreeRTOS

SemaphoreHandle_t mutex = xSemaphoreCreateMutex();
if (mutex != NULL) {
    xSemaphoreTake(mutex, portMAX_DELAY);
    // Access shared resource
    xSemaphoreGive(mutex);
}

This code creates a mutex, takes it to access a shared resource, then gives it back.

Execution Table

Step	Action	Function Call	Result	Notes
1	Call xSemaphoreCreateMutex()	xSemaphoreCreateMutex()	Returns mutex handle	Mutex created successfully
2	Check if mutex is NULL	if (mutex != NULL)	True	Mutex is valid
3	Take mutex	xSemaphoreTake(mutex, portMAX_DELAY)	Mutex taken	Task now owns mutex
4	Access shared resource	N/A	Resource accessed safely	Protected by mutex
5	Give mutex back	xSemaphoreGive(mutex)	Mutex given	Other tasks can take mutex now

💡 Mutex created and used successfully to protect shared resource

Variable Tracker

Variable	Start	After Step 1	After Step 3	After Step 5
mutex	NULL	Valid handle	Taken by task	Given back (available)

Key Moments - 3 Insights

Why do we check if the mutex handle is NULL after creation?

Because xSemaphoreCreateMutex() can fail and return NULL if there is no memory; checking ensures the mutex is valid before use (see execution_table step 2).

What happens if a task tries to take a mutex that is already taken?

The task waits (blocks) until the mutex is given back by the owning task, ensuring exclusive access (implied in step 3 with portMAX_DELAY).

Why must we give the mutex back after accessing the shared resource?

Giving the mutex back allows other tasks to take it and access the resource safely, preventing deadlocks (see execution_table step 5).

Visual Quiz - 3 Questions

Look at the execution table, what is the value of 'mutex' after step 1?

A NULL

B A valid handle to the mutex

C An integer count

D A boolean true

💡 Hint

Check the 'Result' column in row for step 1 in execution_table

At which step does the task gain exclusive access to the shared resource?

A Step 3

B Step 4

C Step 2

D Step 5

💡 Hint

See 'Action' and 'Result' columns in execution_table for step 3

If xSemaphoreCreateMutex() returns NULL, what happens next?

A The mutex is used anyway

B The program crashes immediately

C The code should not take the mutex and handle the error

D The mutex is automatically created later

💡 Hint

Refer to key_moments about checking NULL after creation

Concept Snapshot

xSemaphoreCreateMutex() creates a mutex semaphore and returns its handle.
Check if the handle is NULL before use.
Use xSemaphoreTake() to lock and xSemaphoreGive() to unlock.
Mutex ensures only one task accesses a resource at a time.
Use portMAX_DELAY to wait indefinitely for the mutex.

Full Transcript

The xSemaphoreCreateMutex() function creates a mutex semaphore and returns a handle to it. If creation fails, it returns NULL. After creation, tasks use xSemaphoreTake() to lock the mutex before accessing shared resources, ensuring exclusive access. Once done, tasks call xSemaphoreGive() to release the mutex, allowing other tasks to take it. This mechanism prevents data corruption by serializing access. The execution table shows each step from creation to release, and the variable tracker follows the mutex handle state. Beginners should always check for NULL after creation and understand that taking a mutex blocks if already taken. Giving the mutex back is essential to avoid deadlocks.

Practice

1.

What is the primary purpose of the xSemaphoreCreateMutex() function in FreeRTOS?

easy

A. To delete an existing semaphore

B. To create a counting semaphore for task synchronization

C. To create a mutex for safe access to shared resources

D. To start a new task in the system

Solution

1. Step 1: Understand the function purpose

   xSemaphoreCreateMutex() is designed to create a mutex, which is a special type of semaphore used to protect shared resources.

2. Step 2: Compare with other options

   Options A, B, and C describe different FreeRTOS functions or concepts unrelated to mutex creation.

3. Final Answer:

   To create a mutex for safe access to shared resources -> Option C

4. Quick Check:

   Mutex creation = safe resource sharing [OK]

Hint: Mutexes protect shared resources safely [OK]

Common Mistakes:

• Confusing mutex with counting semaphore
• Thinking it creates a task
• Assuming it deletes semaphores

2.

Which of the following is the correct way to create a mutex using xSemaphoreCreateMutex() in FreeRTOS?

SemaphoreHandle_t mutex = ?;

easy

A. xSemaphoreCreateMutex();

B. xSemaphoreCreateCounting(1, 0);

C. xTaskCreateMutex();

D. xSemaphoreCreateBinary();

Solution

1. Step 1: Identify correct function call

   The function to create a mutex is exactly xSemaphoreCreateMutex(), which returns a handle.

2. Step 2: Eliminate incorrect options

   Options B, C, and D are either different semaphore types or invalid functions.

3. Final Answer:

   xSemaphoreCreateMutex(); -> Option A

4. Quick Check:

   Correct mutex creation syntax = xSemaphoreCreateMutex(); [OK]

Hint: Use exact function name xSemaphoreCreateMutex() [OK]

Common Mistakes:

• Using counting or binary semaphore functions
• Mistyping function name
• Confusing task creation with mutex creation

3.

Consider the following code snippet:

SemaphoreHandle_t mutex = xSemaphoreCreateMutex();
if (mutex == NULL) {
    printf("Mutex creation failed\n");
} else {
    printf("Mutex created successfully\n");
}

What will be the output if the mutex is created successfully?

medium

A. Mutex creation failed

B. Compilation error

C. No output

D. Mutex created successfully

Solution

1. Step 1: Check the return value of xSemaphoreCreateMutex()

   If the mutex is created successfully, the returned handle is not NULL.

2. Step 2: Follow the if-else logic

   Since mutex != NULL, the else block runs, printing "Mutex created successfully".

3. Final Answer:

   Mutex created successfully -> Option D

4. Quick Check:

   Non-NULL handle means success message [OK]

Hint: Check for NULL to confirm creation success [OK]

Common Mistakes:

• Assuming NULL means success
• Ignoring the if-else structure
• Expecting compilation errors

4.

Identify the error in the following code snippet that uses xSemaphoreCreateMutex():

SemaphoreHandle_t mutex;
mutex = xSemaphoreCreateMutex();
if (mutex != NULL) {
    xSemaphoreTake(mutex, 0);
}
// Use shared resource
xSemaphoreGive(mutex);

medium

A. Using zero block time in xSemaphoreTake() may cause immediate failure

B. Mutex handle is not initialized before use

C. xSemaphoreGive() should be called before xSemaphoreTake()

D. xSemaphoreCreateMutex() does not return a handle

Solution

1. Step 1: Analyze xSemaphoreTake() call with zero block time

   Using 0 as block time means the call will not wait and may fail if mutex is not available immediately.

2. Step 2: Understand implications for resource use

   If xSemaphoreTake() fails, the shared resource is accessed without protection, causing potential issues.

3. Final Answer:

   Using zero block time in xSemaphoreTake() may cause immediate failure -> Option A

4. Quick Check:

   Zero block time risks immediate take failure [OK]

Hint: Avoid zero block time unless sure mutex is free [OK]

Common Mistakes:

• Assuming zero block time always succeeds
• Ignoring mutex initialization
• Misordering take and give calls

5.

You want to protect a shared resource in a FreeRTOS application using a mutex created by xSemaphoreCreateMutex(). Which of the following sequences correctly shows how to use the mutex to safely access the resource?

1. xSemaphoreTake(mutex, portMAX_DELAY);
2. Access shared resource
3. xSemaphoreGive(mutex);
4. Create mutex with xSemaphoreCreateMutex()

hard

A. 1, 4, 2, 3

B. 4, 1, 2, 3

C. 4, 2, 1, 3

D. 1, 2, 3, 4

Solution

1. Step 1: Identify correct order of operations

   First, create the mutex (step 4), then take it before accessing the resource (step 1), access the resource (step 2), and finally give the mutex back (step 3).

2. Step 2: Verify sequence correctness

   Only 4, 1, 2, 3 follows the logical order: create, take, access, give.

3. Final Answer:

   4, 1, 2, 3 -> Option B

4. Quick Check:

   Create before take, then access, then give [OK]

Hint: Always create mutex before taking it [OK]

Common Mistakes:

• Taking mutex before creation
• Accessing resource without taking mutex
• Giving mutex before accessing resource