Mutex

A mutex enforces mutual exclusion, meaning only one task or thread can own (hold) the lock at any given time. This ownership is explicit: a task must successfully acquire (lock) the mutex before accessing the shared resource and must release (unlock) it afterward. This prevents concurrent access that could lead to race conditions, data corruption, or inconsistent state, which is catastrophic in real-time control loops where sensor data or actuator commands are shared.

This is a critical feature in real-time systems to mitigate priority inversion. If a low-priority task holds a mutex needed by a high-priority task, the low-priority task's priority is temporarily inherited and raised to that of the waiting high-priority task. This allows it to finish its critical section quickly and release the mutex, minimizing the time the high-priority task is blocked. Without this protocol, a medium-priority task could preempt the low-priority holder, causing unbounded blocking for the high-priority task and potential deadline misses.

Mutex APIs typically offer different acquisition behaviors:

• Blocking Lock: The calling task will block (enter a waiting state) if the mutex is already held, consuming no CPU cycles until the mutex becomes available. This is the standard method.
• Try Lock: A non-blocking call that immediately returns a status indicating success or failure (e.g., mutex_trylock()). This allows a task to attempt access without risking deadlock or to perform alternative work.
• Timed Lock: The task will block but only for a specified maximum duration (e.g., mutex_timedlock()). If the timeout expires, it fails. This is essential for building fault-tolerant systems that must avoid indefinite hangs.

This property defines whether the task that currently owns a mutex can lock it again without deadlocking itself.

• Recursive Mutex: Allows the owning task to acquire the same mutex multiple times. It must release it an equal number of times before it is freed for other tasks. Useful in complex functions that may call other functions needing the same lock.
• Non-Recursive (Standard) Mutex: A second lock attempt by the owning task will typically cause a deadlock or an error. This is simpler and often safer, as it prevents accidental lock nesting and can expose design flaws. In safety-critical robotic code, non-recursive mutexes are often preferred for their predictable behavior.

The implementation location affects performance and functionality:

• Kernel-Managed Mutex: Provided by the RTOS kernel. Offers full features like priority inheritance, robust blocking, and integration with the system scheduler. Acquisition and release involve a context switch into the kernel, adding overhead (e.g., ~1-10 µs).
• User-Space (Futex-based) Mutex: Uses a Fast User-space mutex mechanism. The common case (uncontended lock) is handled entirely in user space using atomic CPU instructions, making it extremely fast. It falls back to a kernel call only when contention requires blocking. This hybrid approach is common in systems like Linux with PREEMPT_RT.

Understanding a mutex requires distinguishing it from related primitives:

• vs. Binary Semaphore: A semaphore is a signaling mechanism with a counter; a binary semaphore (max count=1) can mimic a mutex but lacks the concept of ownership. Any task can release a semaphore, not just the one that acquired it. Mutexes are strictly for protecting shared resources, while semaphores are for signaling and synchronization.
• vs. Spinlock: When a spinlock is contended, the requesting task spins in a tight loop, actively polling the lock. This consumes CPU but avoids context switch overhead. Spinlocks are used for very short critical sections on multi-core systems or in contexts where blocking is prohibited (e.g., some Interrupt Service Routines). Mutexes are used for longer sections where blocking is acceptable.

Multiple threads—such as a high-frequency interrupt service routine (ISR) reading from an IMU and a slower state estimation thread—often read from and write to the same memory buffer. A mutex ensures the state estimation thread sees a complete, coherent sensor packet, preventing it from reading a partially updated buffer that mixes old and new data. This is critical for algorithms like Kalman filters which assume consistent, time-stamped observations.

A robot's joint actuators are a singular physical resource. A motion planning thread calculating a new trajectory and a safety monitoring thread issuing an emergency stop must not write commands simultaneously. A mutex serializes access to the actuator command register or shared memory, guaranteeing that only one valid command (plan or stop) is sent at any instant, preventing dangerous, conflicting signals to the motors.

Robotic systems often allow dynamic reconfiguration (e.g., updating PID gains or control loop rates) via a user interface or network service. A mutex protects the shared structure holding these parameters. This ensures a control thread reading the parameters for its current cycle gets a full, consistent set and does not read a mixture of old and new values mid-update, which could cause instability.

Peripherals like I2C, SPI, or CAN buses are shared resources. If multiple tasks (e.g., reading a temperature sensor and writing to a display) attempt to use the bus concurrently, the electrical signals will collide, corrupting data. A mutex acts as a bus arbiter, granting exclusive access to one task's driver at a time, ensuring each transaction completes atomically.

A robot's internal world model (e.g., a map, object list, or self-pose) is updated by perception threads and read by planning and control threads. A mutex ensures that a planning thread operates on a snapshot-consistent view of the world. Without it, a planner might see a newly detected obstacle but an old robot position, leading to a flawed, potentially unsafe trajectory.

Many third-party or legacy libraries (e.g., for mathematical transforms or file I/O) are not thread-safe—they use static internal buffers. If two tasks call such a function concurrently, their data intermixes in the internal buffer, causing silent corruption. A mutex wrapped around calls to these libraries serializes access, making their use safe in a multi-threaded real-time operating system (RTOS) environment.

A semaphore is a synchronization primitive that controls access to a shared resource by maintaining a count. Unlike a mutex, which enforces strict mutual exclusion (one holder), a semaphore allows a specified number of concurrent accesses.

• Counting Semaphore: Manages access to a pool of identical resources (e.g., 5 available database connections).
• Binary Semaphore: A semaphore with a count of one, which can be used similarly to a mutex but with a key semantic difference: it can be released by a different task than the one that acquired it.
• Key Distinction from Mutex: A mutex includes the concept of ownership; only the task that locked it can unlock it. This enables priority inheritance protocols to prevent priority inversion.

Priority inversion is a critical scheduling problem where a high-priority task is forced to wait indefinitely for a lower-priority task to release a shared resource (like a mutex). This violates the expected priority-based execution order.

• Classic Scenario: A low-priority task (L) locks a mutex. A high-priority task (H) preempts L but then blocks, waiting for the same mutex. A medium-priority task (M) can now run, preempting L, thereby indirectly blocking H.
• Solution - Priority Inheritance: When H blocks on a mutex held by L, the mutex protocol temporarily elevates L's priority to that of H. This allows L to finish its critical section quickly, release the mutex, and let H proceed. Most RTOS mutex implementations support this.

A spinlock is a low-level locking primitive where a thread repeatedly polls (or "spins") in a tight loop, waiting for a lock to become available, instead of yielding the processor.

• Use Case: Designed for very short critical sections on multi-core systems or in kernel code where the cost of a full context switch is higher than the expected spin time.
• Trade-off: Eliminates context switch overhead but wastes CPU cycles while spinning. Dangerous on single-core systems as it can lead to deadlock if the locking thread is preempted.
• Contrast with Mutex: A mutex typically puts the waiting task into a blocked state, allowing the scheduler to run other tasks. A spinlock keeps the CPU core busy.

Deadlock is a system state where two or more tasks are permanently blocked, each waiting for a resource held by another. It's a fundamental hazard in concurrent programming that mutexes can inadvertently cause.

• The Four Coffman Conditions: All four must hold for deadlock: 1) Mutual Exclusion, 2) Hold and Wait, 3) No Preemption, 4) Circular Wait.
• Common Example (Circular Wait): Task A locks Mutex 1 and then tries to lock Mutex 2. Simultaneously, Task B locks Mutex 2 and then tries to lock Mutex 1. Both tasks block forever.
• Prevention Strategies:
  • Lock Ordering: Always acquire multiple mutexes in a globally defined, consistent order.
  • Timeout: Use a timed try_lock operation to break the hold-and-wait condition.
  • Design: Minimize the need for holding multiple locks.

Lock-free programming is a concurrency paradigm where data structures are designed so that multiple threads can access shared data without using mutual exclusion locks (mutexes). Progress is guaranteed for at least one thread.

• Mechanism: Relies on atomic operations (e.g., Compare-And-Swap) provided by the CPU to update shared state. If a conflict occurs, one thread's operation succeeds while others retry.
• Advantages: Eliminates priority inversion, deadlock, and convoying. Can provide higher throughput under high contention.
• Disadvantages & Complexity: Significantly more complex to design and verify correctly. Not always faster; lock-based algorithms can be superior under low contention. "Wait-free" is a stronger guarantee where every thread makes progress in a finite number of steps.

A condition variable is a synchronization primitive that allows a thread to block until a particular condition on shared data becomes true. It is always used in conjunction with a mutex.

• Typical Pattern: A thread:
  1. Acquires a mutex.
  2. Checks a condition (e.g., is_queue_empty?).
  3. If false, it waits on the condition variable, which atomically releases the mutex and blocks the thread.
  4. When signaled by another thread, it re-acquires the mutex and re-checks the condition.
• Operations: wait(mutex), signal() (wakes one waiter), broadcast() (wakes all waiters).
• Purpose: Enables efficient waiting for state changes without busy-waiting, separating the concerns of mutual exclusion (mutex) and event signaling (condition variable).