# Mutex vs Semaphore

URL: https://softwaredictionary.org/compare/mutex-vs-semaphore
Last updated: 2026-09-30

In short: A mutex lets one thread at a time use a shared resource and only its owner releases it, while a semaphore is a counter that lets up to N threads in at once.

## What is the difference between a mutex and a semaphore?

A mutex (mutual exclusion lock) protects a critical section: a thread locks it, works with the shared data and unlocks it, while other threads wait their turn. A semaphore holds a counter of available permits: `acquire` (also called wait or P) decreases it and blocks at zero, and `release` (signal or V) increases it and wakes a waiting thread.

The key differences are ownership and count. A mutex has an owner, and only the thread that locked it should unlock it, which lets systems detect mistakes and handle priority inversion. A semaphore has no owner and can allow several holders at once, so it fits limiting access to a pool of N resources, like database connections, or signaling between threads, where one thread releases and another acquires.

They are often used side by side. A bounded queue between producers and consumers typically uses a mutex to protect the queue itself and two counting semaphores to track free slots and filled items. Many languages also build higher-level tools, like channels and connection pools, on top of these two primitives.

A common misconception is that a binary semaphore, one with a count of 1, is the same as a mutex. It also allows one holder at a time, but any thread can release it and there is no owner, so it cannot catch a thread unlocking someone else's lock or support features like recursive locking and priority inheritance.

| Aspect | Mutex | Semaphore |
| --- | --- | --- |
| What it is | A lock with an owner | A counter of available permits |
| Holders at once | Exactly one | Up to N, the initial count |
| Who releases it | Only the thread that locked it | Any thread |
| Main purpose | Protect shared data from concurrent changes | Limit access to N resources or signal between threads |
| Operations | lock and unlock | acquire (wait, P) and release (signal, V) |
| Extra features | Often recursive locking and priority inheritance | Can count events and coordinate producers and consumers |
| Typical use | Updating a shared counter, map or file | Connection pools, concurrency limits, bounded queues |

## Choose Mutex when

- Only one thread at a time may touch a piece of shared data.
- The thread that locks is always the one that unlocks.
- You need protection against priority inversion in real-time systems.

## Choose Semaphore when

- Up to N threads may use a pool of resources at the same time.
- One thread needs to signal another that work is ready.
- You want to cap concurrency, such as parallel downloads or API calls.

## Frequently asked questions

**Is a binary semaphore the same as a mutex?**

Not quite. Both allow one holder at a time, but a mutex has an owner that must unlock it, while any thread can release a binary semaphore.

**When should I use a semaphore instead of a mutex?**

Use a semaphore when more than one thread may proceed at once, such as limiting work to five database connections, or when one thread must signal another. Use a mutex to protect shared data.

**Can a mutex cause a deadlock?**

Yes. If two threads each hold one mutex and wait for the other's, neither can continue. Always acquiring locks in the same order is a common way to prevent it.

---

Software Dictionary: https://softwaredictionary.org/ · https://softwaredictionary.org/llms.txt