Side by side

MutexvsSemaphore

What is the difference between a mutex and a semaphore?

Updated September 30, 20262 min read7 differences

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.

Operating Systemsp. 20

Mutex

Mutual Exclusion

A mutex is a lock that lets only one thread at a time enter a critical section of code, so threads can't corrupt shared data by changing it at the same time.

Read the page on Mutex

Operating Systemsp. 26

Semaphore

A semaphore is a synchronization tool that keeps a counter of available permits, letting up to a fixed number of threads use a resource at the same time.

Read the page on Semaphore

Mutex and Semaphore compared

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

The difference, explained

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.

Which one should you use?

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.

One at a time vs up to three at a time

Mutexpython

import threading

lock = threading.Lock()
balance = 0

def deposit(amount):
    global balance
    with lock:  # only one thread at a time
        balance += amount

Semaphorepython

import threading

permits = threading.Semaphore(3)  # three permits

def download(url):
    with permits:  # up to three threads at once
        fetch(url)

Readers ask

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.