Katkat
Back

How a C++ Mutex Protects Shared State

MillenniumSoftware Engineer · Onsite
MediumSoftware EngineerOnsiteSoftware Engineering Fundamentals

Last updated

Explain C++ mutex ownership, memory visibility, RAII locking, contention, and deadlock prevention with a shared-counter example.

How does a mutex work in C++, and what must an application do for it to protect shared state correctly?

Explain the language-level guarantee, a possible implementation of an uncontended versus contended lock, and a short C++ example that increments shared state safely. Discuss what goes wrong when only some accesses follow the locking rule.

Constraints & Assumptions

  • Use std::mutex and ordinary C++ threads.
  • The shared state is a non-atomic counter accessed by more than one thread.
  • Assume the mutex and counter remain alive until all worker threads have finished.
  • Distinguish standard guarantees from implementation choices; do not assume a particular operating-system primitive, fairness policy, or spin duration.

Clarifying Questions to Ask

  • Must the protected state satisfy an invariant across several fields, or is it just one counter?
  • Can code in the critical section throw or return early?
  • Can the operation acquire another mutex, or re-enter a function that takes the same mutex?

Hints

Hint 1

Ownership and visibility are separate concerns: Explain both why two threads cannot own the same mutex at once and why a later owner can observe writes made by an earlier owner.

Follow-up questions

  • How would you safely lock two mutexes needed by one operation?
  • When would `std::unique_lock` be more appropriate than `std::lock_guard`?