What is Mutex? Explained With Example

The term mutual exclusion or mutex (abbreviation for mutual ual exclusion) refers to a group of procedures with which the problem of the critical section is solved. Mutex methods prevent concurrent processes or threads from changing shared data structures in an uncoordinated manner at the same time or in a temporally entangled manner, which can cause the data structures to become inconsistent, even if the actions of each individual process or thread are consistent in their own right. Mutex methods coordinate the timing of concurrent processes/threads in such a way that other processes/threads are excluded from executing critical sections if a process/thread is already in the critical section (changes the data structure).

Mutex methods are assigned to the class of process or thread synchronization methods and are of central importance for any systems of concurrent processes/threads with modifying access to shared data or data structures, e.g. also for client/server systems with independent client processes or threads that access a database server simultaneously or temporally interlocked.

Mutexes operate on the principle of ownership. When a thread acquires a mutex lock, it gains exclusive ownership of the associated resource. Subsequent attempts by other threads to acquire the same mutex are blocked until the owning thread releases the lock, making the resource available for access by another thread.

Demarcation of Mutex

The term mutex is not uniformly defined. It is often used differently in theoretical computer science than in specific programming languages. This section attempts to give the most common definition of the terms.

1. Mutex: The procedure for ensuring mutual exclusion (see above). An object (or data structure) that enforces mutual exclusion. Most programming languages that support concurrent processes have one. It is by no means identical with a binary semaphore, as semaphores may be released by other activity carriers.
2. Semaphor is a data structure used to control restrictive access to data, with or without a connection to a task scheduler. The general meaning of semaphore goes back to optical telegraphy with signal poles (Semaphore telegraph).
3. Monitor is a mechanism for controlling restrictive access to data in conjunction with the computational time distribution (scheduler) of a real-time operating system (RTOS) or a language that supports multithreaded processing, such as in Java. Conceptually, the semaphore and monitor technology are related.
4. Lock mechanisms are used to block access from another party during an ongoing edit, for example file locks when writing to a file or locking a specific revision in a version control system.
5. A critical section or critical region is the part of executable code in which undisturbed access to data occurs due to the mutex. A critical section must not be interrupted
   – from another thread that wants to access the same mutex-protected data,
   – from another thread, which would potentially unduly extend mutex access because it interrupts the accessing thread for an extended period of time.

There are several types of mutexes, each with its own characteristics and use cases. Here are some common types of mutexes:

Binary Mutex (Binary Semaphore):

• Also known as a binary semaphore, it has two states: locked and unlocked.
• Provides simple mutual exclusion, allowing only one thread to access the resource at a time.
• Typically used in scenarios where only one resource needs to be protected.

Reentrant Mutex:

• Also known as a recursive mutex, it allows the same thread to acquire the mutex multiple times without causing a deadlock.
• The thread must release the mutex the same number of times it acquired it.
• Useful in scenarios where a function or code block needs to lock the mutex recursively.

Timed Mutex:

• Allows a thread to attempt to acquire a lock on the mutex for a specified duration.
• If the mutex cannot be acquired within the specified time, the thread can perform other tasks or handle the situation accordingly.
• Helps prevent potential deadlocks or indefinite waits for locks.

Priority Inheritance Mutex:

• Helps prevent priority inversion in real-time systems where tasks have different priorities.
• If a lower-priority task holds a mutex needed by a higher-priority task, the priority of the lower-priority task is temporarily raised to that of the higher-priority task.
• Ensures that the higher-priority task can proceed without unnecessary delay.

Error-Checking Mutex:

• Provides additional error-checking capabilities, allowing threads to check whether they successfully acquired or released the mutex.
• Helps in debugging and identifying issues related to mutex usage.

Adaptive Mutex:

• Also known as a spinlock or busy-wait mutex, it avoids context switches when the lock is heavily contended.
• Instead of putting the thread to sleep, it spins in a loop until the lock becomes available.
  Suitable for scenarios where lock contention is brief or where the cost of context switching is high.

Fair Mutex:

• Ensures fairness in lock acquisition, where threads waiting for the mutex are served in the order they requested the lock.
• Prevents starvation, where a thread may never acquire the lock due to other threads continually acquiring it.

Read-Write Mutex:

• Allows multiple threads to concurrently read a shared resource but ensures exclusive access for writing.
• Optimizes performance by allowing multiple readers to access the resource simultaneously while maintaining data consistency.

Terms Related to Mutex

In computer science, polling is a mechanism for continuous queries, for example whether a lock is still active or whether a semaphore is free. Polling is an alternative to control via a scheduler.

Active waiting (busy-waiting) is a continuous polling for a mutex release. Polling does not have to (and should not!) be done unnecessarily often. It makes sense to combine active waiting with a thread submission to a scheduler controller for a defined time with a “sleep” call (to release computing time or to save power).
Spinlock is the combination of lock with polling.

Process synchronization is the general term for coordinating the timing of multiple concurrent processes or threads. It does not matter whether they are threads in a program, programs on a computer or processes in a distributed system. With regard to mutex, the processes only need to be synchronized for the short period of mutex access and only in such a way that they do not access at the same time. General process synchronization is not associated with this.

Interprocess communication is the collective term for methods for exchanging data between processes and achieving process synchronization. A mutex itself is not a means of interprocess communication, but the exchange of data, which may be protected by a mutex, can be such a means.

Support for Mutex by Programming Languages

Some programming languages support mutex as part of the language itself, especially Concurrent Pascal, Ada, Java, or C#. For almost all languages, there are libraries that implement a mutex system, and this is often even part of the standard API or runtime environment.

A good implementation of Mutex is only possible with an operating system whose scheduler supports such concepts. On other systems (especially real-time systems), spinlocks have to be used, which significantly affect system performance through busy waiting.

In principle, it is sufficient for an operating system or runtime environment to offer a subset of mutex, semaphore, monitor, lock or critical section. Each of these principles can be modeled by any other from the group.

Code Example of Mutex

Consider a scenario where multiple threads are concurrently updating a shared counter variable. Without synchronization, race conditions may occur, leading to incorrect results. Let’s illustrate this with C++ code:

In this example, two threads (t1 and t2) are concurrently executing the incrementCounter() function, which increments the sharedCounter variable. To prevent race conditions, a mutex (mtx) is used to synchronize access to sharedCounter. The lock() and unlock() methods of the mutex ensure that only one thread can modify sharedCounter at a time.

Using a mutex in Arduino, especially on microcontrollers like those used in Arduino boards, is a bit different from traditional multithreading environments due to the constraints of the hardware and the single-threaded nature of Arduino sketches. However, you can still simulate mutual exclusion using techniques like disabling interrupts or using atomic operations.

Here’s a simple example demonstrating the concept of mutual exclusion using a mutex-like behavior in an Arduino sketch:

volatile int sharedResource: This variable represents the shared resource that multiple threads (simulated in the loop) will try to access concurrently.

incrementCounter(): This function simulates a critical section where access to the shared resource needs to be mutually exclusive. To achieve this, interrupts are temporarily disabled using noInterrupts(), ensuring that no interrupt-driven events can occur during the critical section. After modifying the shared resource, interrupts are re-enabled using interrupts().

setup() and loop(): Standard Arduino functions. In loop(), we simulate two threads trying to increment the shared resource concurrently. We print the value of the shared resource after each increment to observe its behavior.

While this example doesn’t use a traditional mutex, it demonstrates a simple form of mutual exclusion in Arduino, essential for ensuring data integrity in scenarios where shared resources are accessed by multiple concurrent events.