Introduction to RTOS Part 6 - Mutex | Digi-Key Electronics

Name: Introduction to RTOS Part 6 - Mutex | Digi-Key Electronics
Uploaded: 2021-02-15T14:30:01.000Z
Duration: 26 min 44 s

Understanding Race Conditions in Concurrent Programming

Introduction to Race Conditions

A race condition is a common issue in concurrent programming, particularly when multiple tasks access shared resources like global variables.

The problem arises when tasks modify and write to a shared resource without control over the timing of interruptions from other threads.

Exploring the Problem

Cues can facilitate inter-task communication but may not suffice for scenarios requiring global variables as flags or counters.

A simple example illustrates two tasks (A and B) accessing a global variable, highlighting potential issues if updates require multiple instruction cycles.

Mechanics of Race Conditions

A race condition occurs when system behavior depends on the timing of uncontrollable events, leading to unpredictable results.

In the provided pseudocode example, both tasks increment a global variable indefinitely, demonstrating how race conditions manifest.

Detailed Example of Race Condition

Task A retrieves and increments a global variable while Task B interrupts it. This leads to incorrect final values due to overlapping operations.

The sequence of execution affects outcomes; if one task preempts another during critical operations, it can result in missed increments.

Demonstrating with FreeRTOS

An experiment using FreeRTOS shows how two tasks running an increment function can lead to inconsistent results due to race conditions.

The implementation includes random delays between increments, making it easier to observe the effects of race conditions on the global variable.

Critical Sections and Mutual Exclusion

Understanding Critical Sections

Code sections that manipulate shared resources must execute completely before being accessed by other tasks; these are termed critical sections.

Enforcing Mutual Exclusion

Mutual exclusion prevents simultaneous access by multiple threads. Various methods exist for enforcing this principle in concurrent programming environments.

Kernel Objects for Synchronization

Cues allow message passing between threads and can be used as locking mechanisms for entering critical sections safely within FreeRTOS.

Understanding Mutexes and Semaphores in FreeRTOS

Introduction to Mutexes and Semaphores

A lock functions for all processes in a system; in FreeRTOS, a lock is equivalent to a mutex.

A semaphore, similar to a mutex, includes a counter that permits multiple threads limited access to critical sections.

The restroom analogy illustrates how mutexes restrict access: only one person can use the restroom (shared resource) at any time.

How Mutexes Work

In the example, the mutex acts as a key for accessing the shared resource; it ensures that only one thread can enter at once.

Task A checks if the mutex exists and takes it atomically; this prevents interruptions during the check-and-take process.

If Task B attempts to access while Task A holds the mutex, it will fail and must wait until Task A releases it.

Critical Section Execution

Once Task A completes its operations within the critical section, it returns the mutex by setting its value back to 1.

When Task B runs again and finds the mutex available, it can proceed with its own critical section without interference from other threads.

Implementing Mutexes in FreeRTOS

To implement this concept in FreeRTOS, include necessary headers for semaphores and create a global mutex using xSemaphoreCreateMutex().

Use xSemaphoreTake() function within task functions to attempt taking the mutex; specify timeout parameters for blocking or non-blocking behavior.

Practical Application of Mutexes

After incrementing shared variables within critical sections, return the mutex using xSemaphoreGive(), allowing other tasks access afterward.

It’s important not to give or take semaphores inside interrupt service routines directly; instead use ISR-safe functions provided by FreeRTOS.

Challenge: Passing Parameters Safely

The challenge involves passing local stack memory variables safely when creating tasks due to potential scope issues after function execution ends.

Understanding Scope and Mutex in Programming

The Importance of Variable Scope

The concept of variable scope is introduced, highlighting that a value may no longer exist if it goes out of scope. In this case, when the program prompts for a number, the entered value is passed to a task but exits before being utilized.

As a result of exiting too early, the variable num defaults to zero because it was not properly read before going out of scope.

A mutex is suggested as a solution to prevent premature exit from the setup phase, ensuring that the parameters are fully read before moving on.

Misuse of Mutex: A Hack or Necessity?

The speaker acknowledges that using a mutex in this context is more akin to employing a semaphore rather than proper mutex usage.

This approach serves as an interim solution to signal another task effectively, which will be further explored in upcoming discussions about semaphores.