Mutex Basics and Critical Sections

Imagine a program in which one thread must update two separate pieces of shared data. Each piece is protected by its own mutex. For the duration of the update, the thread now holds, or needs to hold, two locks at the same moment. Taking one lock and then the other sounds simple, but the way the locks are acquired, and what the thread does while it waits for them, determines whether the program stays safe.

This article looks at one specific tool for this job: a single lock() call that receives several mutexes, working together with unique_lock objects. The guiding question is a simple one. When a thread asks for several mutexes at once, what does the program actually guarantee?

Before reading the rules, follow the path a thread takes. The diagram below starts at the moment a thread calls lock() with several mutexes and ends when those mutexes are returned to the system. Read it from the top. The thread cannot move past the acquisition step until every mutex argument has been acquired, and the release happens at the end of the scope rather than at an explicit unlock line.

The flowchart shows the order of events, not the internal mechanics of how acquisition is carried out, and it does not depend on any particular implementation. What it captures is the structure the source describes: an acquisition step that completes fully before the work begins, followed by a cleanup step tied to the scope.

These two promises work together. The first guarantees completeness: the thread never proceeds with a partial set of locks. The second guarantees that the waiting itself is handled safely, so a thread is not left holding one mutex while stuck behind another. Together they make a multi-lock acquisition safer than a sequence of ordinary single-lock calls, where each call waits in turn while the earlier locks remain held.

Consider the two approaches side by side. In the naive approach, a thread takes one mutex, then calls for the second as a separate step. In the single-call approach, the thread asks for both mutexes in one lock() call. The diagram compares the state of the mutexes before the call and after it returns, for the single-call approach.

When lock() returns, both mutexes are held, and the code after the call is the first point at which the thread is working with both. In the naive approach, there is an intermediate moment in which m1 is held while the thread is still waiting for m2. The single call is designed so that this intermediate waiting-while-holding state is not what the call does: the call does not wait on one mutex while keeping another locked.

The next diagram shows why the one-at-a-time pattern is risky. It uses two threads that take the same two mutexes in opposite orders. This illustration is a generated teaching example that follows the reasoning above, not a scenario described in the source.

Each thread holds one mutex and waits for the other. Neither can proceed, because each is waiting on a lock the other will not release until it finishes. A single lock() call that acquires both mutexes at once removes the intermediate state in which one thread holds a lock while waiting for another, which is exactly the kind of waiting that this sequence illustrates.

Acquiring the locks is only half of the story. The other half is making sure they are given back. The source attributes this job to the destructors of the individual unique_lock objects. A destructor is the cleanup routine that runs automatically when an object's lifetime ends. Because each mutex is wrapped in its own unique_lock, the release of each mutex is tied to the lifetime of that wrapper.

The practical consequence is that the programmer does not need to remember a separate release step for every mutex. When a thread leaves the scope in which its unique_lock objects were created, their destructors run and the mutexes they guard are released. The scope, not a manual instruction, controls the moment of release.

The region of code that is protected while the mutexes are held is the place where the thread does its critical work on the shared data. The source's guarantee covers acquisition and non-blocking behavior. It does not cover every action a thread takes while it holds the locks. That means safe multi-lock code also depends on keeping the held region focused: the longer and broader the work done while holding the locks, the more the program depends on what that work does.