Synchronization Primitives: Mutexes, Semaphores, and Spinlocks

1. The Core Problem: Critical Sections and Race Conditions

A critical section is a piece of code that accesses a shared resource and must not be simultaneously executed by more than one task. To enforce this, we use synchronization primitives to "lock" the critical section.

Imagine a simple global counter updated by two tasks:

volatile uint32_t g_shared_counter = 0;

void task_A(void) {
    g_shared_counter++; 
}

void task_B(void) {
    g_shared_counter++;
}

The g_shared_counter++ operation seems atomic, but it compiles to multiple assembly instructions:

1. LOAD the value of g_shared_counter from memory into a CPU register.
2. INCREMENT the value in the CPU register.
3. STORE the new value from the CPU register back to memory.

Now, consider this sequence:

1. task_A executes step 1 (loads g_shared_counter, which is 0, into its register).
2. A context switch occurs! task_A is preempted.
3. task_B runs, executes all three steps, and increments g_shared_counter to 1.
4. Another context switch occurs. task_A resumes.
5. task_A executes step 2 (increments its register, which still holds 0, to 1).
6. task_A executes step 3 (stores 1 back into g_shared_counter).

Result: The counter is 1, even though it was incremented twice. We lost an update. This is a classic race condition.

To solve this, we need to make the three-step sequence an indivisible, atomic operation. This is where our three primitives come in.

2. The Spinlock: Busy-Waiting for Access

A spinlock is the simplest type of lock. When a task tries to acquire a spinlock that is already held, it doesn't go to sleep. Instead, it enters a tight loop, "spinning" and repeatedly checking the lock until it becomes free.

This requires a special hardware instruction that can check the lock's state and acquire it in a single, uninterruptible operation.

Spinlocks and Interrupts: A Classic Deadlock

Spinlocks are fast but have a critical weakness on single-core systems. If a task holds a spinlock and is preempted by an interrupt whose handler also tries to acquire the same spinlock, the system will deadlock. The ISR will spin forever, waiting for the task to release the lock, but the task can't run to release the lock because the ISR has preempted it.

The key takeaway is that when a spinlock is acquired on a single-core system, interrupts must be disabled to prevent this deadlock scenario.

When to use a Spinlock:

• Multi-core systems: Where the task holding the lock is on another core and is expected to release it very quickly. The waiting core can spin for a few cycles instead of paying the high cost of a context switch.
• Kernel/Driver code: For protecting extremely short critical sections (e.g., modifying a few linked list pointers) where the overhead of a context switch is unacceptable.
• When you absolutely cannot sleep: Such as in certain parts of an interrupt handler (though this is very advanced and requires careful design).

3. The Mutex: Sleeping with Ownership

A Mutex (short for Mutual Exclusion) is a more sophisticated lock. If a task tries to acquire a mutex that is already held, the RTOS puts the task to sleep (blocks it). The RTOS then schedules another ready task to run. When the mutex is released, the RTOS will wake up the blocked task and move it to the ready state.

This avoids the wasted CPU cycles of busy-waiting, making it far more efficient for general-purpose use.

The defining characteristic that separates a mutex from a binary semaphore is ownership.

When to use a Mutex:

• The default choice for protecting a shared resource in an RTOS application.
• When the critical section might be long, or the task might have to wait for an I/O operation while holding the lock (though this is often a sign of poor design).
• When you need features like recursive locking or priority inheritance.

When NOT to use a Mutex:

• In an ISR: Interrupt handlers cannot sleep, so they cannot block on a mutex.
• For simple signaling: A mutex is designed for protecting resources, not for synchronizing execution between tasks (e.g., signaling that data is ready). That's a job for a semaphore.

4. The Semaphore: The Universal Signaling Tool

A semaphore is not primarily a locking mechanism; it's a signaling mechanism. It behaves like a counter with two atomic operations:

• wait (or pend, take): Decrements the semaphore's count. If the count is zero, the task blocks until the count becomes greater than zero.
• post (or signal, give): Increments the semaphore's count. If any tasks are blocked waiting for the semaphore, one of them is unblocked.

Unlike a mutex, a semaphore has no concept of ownership. Any task can post to a semaphore, even if it never waited on it. This is what makes it so flexible for synchronization.

There are two main types of semaphores:

• Counting Semaphore: The count can range from 0 to some maximum value. This is used to manage a pool of identical resources.
  • Example: You have a pool of 4 network buffers. Initialize a semaphore with a count of 4. Tasks wanting a buffer must first wait on the semaphore. When they are done, they post to the semaphore, making the buffer available to another task.
• Binary Semaphore: The count is restricted to 0 or 1. It can be used for mutual exclusion (like a mutex), but this is generally discouraged because it lacks ownership and the associated safety features. Its primary use is for pure signaling.
  • Example: An ISR for a UART receives a complete data packet. It then posts a binary semaphore. A high-priority worker task, which was blocked waiting on that semaphore, now wakes up and processes the packet.

The producer-consumer problem is the classic use case for semaphores.

5. Summary and Selection Guide

Choosing the right tool is critical. A wrong choice can lead to subtle bugs, deadlocks, or poor performance.

Here is a summary table to guide your decision-making process, a crucial skill for system design interviews.

Interview-Style Scenarios

Let's test your understanding. For each scenario, which primitive would you choose and why?

1. Scenario A: You have multiple tasks that need to write log messages to a single UART peripheral. You need to ensure that messages from different tasks are not interleaved.
2. Scenario B: An I2C driver in a Linux kernel needs to protect its internal data structure during read/write operations. The critical sections are very short, just a few instructions, and these operations are frequent. The system is multi-core.
3. Scenario C: An ADC completes a conversion and triggers an interrupt. The ISR needs to notify a background task to fetch the ADC value and perform a filtering calculation.
4. Scenario D: A web server application has a pool of 10 worker threads and a pool of 5 available database connections. You need to manage access to these connections.

Conclusion

You now have a solid framework for differentiating between these three fundamental synchronization primitives.

Key Takeaways:

• Spinlock: For performance-critical, short-duration locks in low-level code (like kernels), especially on multi-core systems. It busy-waits.
• Mutex: The standard choice for general-purpose resource protection in an RTOS. It causes tasks to block (sleep) and enforces ownership.
• Semaphore: The tool for signaling and synchronization. It has no ownership, making it perfect for ISR-to-task communication and managing pools of resources. It also causes tasks to block (sleep).

Being able to clearly articulate these trade-offs is a hallmark of a senior embedded engineer.

Preview of the Next Lesson:

We've mentioned that a key benefit of mutex ownership is the ability to solve priority inversion. This dangerous condition occurs when a high-priority task is forced to wait for a lower-priority task, effectively "inverting" their priorities and jeopardizing real-time deadlines. In our next lesson, we will explore this problem in detail and examine the common solutions: the Priority Inheritance Protocol (PIP) and the Priority Ceiling Protocol (PCP).