Semaphore vs Mutex — Trading Engine Priority Inversion

Every production system that handles concurrency — web servers juggling thousands of requests, database connection pools, real-time trading engines — relies on two primitives to stay sane: semaphores and mutexes. Get them wrong and you don't get a compiler error. You get a data race that only shows up under load at 2 AM on a Friday. That's why this topic matters — the bugs it prevents are the ones that end careers.

The problem both primitives solve is the same: shared state modified by multiple threads simultaneously produces unpredictable results. Without coordination, two threads can read the same value, each increment it, and write back — losing one update entirely. This is the classic lost-update problem, and it's been killing software since the 1960s. Semaphores and mutexes are the industry's answer, but they solve subtly different problems, and using the wrong one is a trap senior engineers fall into too.

By the end of this article you'll understand exactly how each primitive works at the kernel level, why ownership semantics change everything, how to implement both correctly in Java, how to identify priority inversion and deadlock in production, and — critically — you'll have a decision framework for choosing between them that you can apply immediately in code reviews or system design interviews.

Semaphore vs Mutex — The Ownership Rule That Breaks Trading Engines

A mutex is a binary lock with ownership: only the thread that acquired it can release it. A semaphore is a signaling counter that any thread can increment (release) or decrement (acquire). The core mechanic: mutex prevents concurrent access to a critical section; semaphore controls access to a finite pool of resources.

In practice, mutexes enforce strict ownership, which enables priority inheritance protocols — critical for real-time systems. Semaphores, lacking ownership, cannot support inheritance. This means a low-priority thread holding a semaphore can block a high-priority thread indefinitely, causing priority inversion. Counting semaphores (N > 1) allow up to N concurrent threads; binary semaphores (N = 1) behave like a mutex but without ownership.

Use mutexes when protecting a shared resource where the holder must be identifiable — e.g., a trading engine's order book. Use semaphores for resource pooling (e.g., connection pools, thread pools) where any thread can signal availability. In latency-sensitive systems, choosing the wrong primitive directly causes unbounded priority inversion, leading to missed SLAs.

How Mutexes Actually Work — Ownership, Kernel Mode and the Futex Trick

A mutex (mutual exclusion lock) is a binary lock with strict ownership: the thread that acquires it is the only thread allowed to release it. This sounds simple, but the implementation is where things get interesting.

On Linux, modern mutexes are built on futexes (Fast Userspace muTEXes). The insight is that most of the time, a mutex is uncontested — no other thread is waiting. In that happy path, acquiring and releasing the lock is just an atomic CAS (compare-and-swap) on a 32-bit integer in userspace. Zero kernel involvement. Zero syscall overhead. That's why a good mutex is blazingly fast under low contention.

Only when contention happens — when thread B tries to lock what thread A already holds — does the kernel get involved. The kernel parks thread B in a wait queue, puts it to sleep, and wakes it up when thread A calls unlock. This park/unpark cycle is expensive (microseconds, not nanoseconds), which is why you should minimize lock hold time aggressively.

Java's synchronized keyword and ReentrantLock both map to this model. ReentrantLock adds re-entrancy: the owning thread can acquire the same lock multiple times without deadlocking itself, as long as it releases it the same number of times. That counter is tracked per-thread in the lock's internal state.

import java.util.concurrent.locks.ReentrantLock;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.TimeUnit;

/**
 * Demonstrates a mutex (ReentrantLock) protecting a shared bank account balance.
 * Two threads attempt concurrent withdrawals — the mutex ensures correctness.
 */
public class BankAccountWithMutex {

    private double balance;
    // ReentrantLock is Java's explicit mutex — it has ownership semantics:
    // only the thread that called lock() is allowed to call unlock().
    private final ReentrantLock balanceLock = new ReentrantLock();

    public BankAccountWithMutex(double initialBalance) {
        this.balance = initialBalance;
    }

    /**
     * Withdraws an amount if sufficient funds exist.
     * Returns true if the withdrawal succeeded, false otherwise.
     */
    public boolean withdraw(String threadName, double amount) {
        // lock() blocks until THIS thread owns the lock.
        // No other thread can enter this block simultaneously.
        balanceLock.lock();
        try {
            System.out.printf("[%s] Acquired lock. Balance: %.2f, Requesting: %.2f%n",
                    threadName, balance, amount);

            if (balance < amount) {
                System.out.printf("[%s] Insufficient funds. Withdrawal denied.%n", threadName);
                return false;
            }

            // Simulate some processing time — this is the critical section.
            // Without the mutex, two threads could both pass the balance check
            // and both withdraw, leaving the account negative.
            Thread.sleep(50); // checked exception handled by try-catch below
            balance -= amount;

            System.out.printf("[%s] Withdrew %.2f. New balance: %.2f%n",
                    threadName, amount, balance);
            return true;

        } catch (InterruptedException interruptedException) {
            Thread.currentThread().interrupt(); // restore interrupt flag — NEVER swallow this
            return false;
        } finally {
            // ALWAYS release in a finally block — if an exception is thrown above,
            // the lock MUST still be released or every other thread waits forever.
            balanceLock.unlock();
            System.out.printf("[%s] Released lock.%n", threadName);
        }
    }

    public static void main(String[] args) throws InterruptedException {
        BankAccountWithMutex account = new BankAccountWithMutex(100.00);
        ExecutorService executor = Executors.newFixedThreadPool(2);

        // Both threads attempt to withdraw 80 — only one should succeed.
        executor.submit(() -> account.withdraw("Thread-Alice", 80.00));
        executor.submit(() -> account.withdraw("Thread-Bob",   80.00));

        executor.shutdown();
        executor.awaitTermination(5, TimeUnit.SECONDS);
        System.out.printf("%nFinal balance: %.2f%n", account.balance);
    }
}

How Semaphores Actually Work — Counting, Signaling and Why Ownership Doesn't Exist

A semaphore maintains an integer counter and two atomic operations: acquire (decrement, block if zero) and release (increment, wake a waiter if any). The critical architectural difference from a mutex: any thread can call release, regardless of which thread called acquire. There is no ownership.

This makes semaphores a signaling primitive, not a locking primitive. Thread A can acquire a semaphore and thread B can release it. That's intentional — it's what makes semaphores ideal for producer-consumer scenarios where one thread produces a resource and another consumes it.

A binary semaphore (max count = 1) looks superficially like a mutex, but lacks ownership. This distinction has real consequences: a binary semaphore can be released by a thread that never acquired it, which can corrupt your invariant. This is why the advice 'a binary semaphore is the same as a mutex' is dangerously wrong.

Under the hood, Java's Semaphore class uses AbstractQueuedSynchronizer (AQS) — the same framework backing ReentrantLock. AQS maintains a CLH queue of waiting threads and an atomic state integer. For a semaphore initialized with N permits, the state starts at N. Each acquire does an atomic decrement; each release does an atomic increment and unparks a waiting thread if one exists. Fair vs unfair mode determines whether waiting threads are served FIFO or allowed to barge in — unfair is faster but can starve threads.

import java.util.concurrent.Semaphore;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.TimeUnit;
import java.util.ArrayDeque;
import java.util.Queue;

/**
 * A simplified database connection pool backed by a Semaphore.
 * The semaphore acts as a ticket counter: only MAX_CONNECTIONS threads
 * can hold a connection simultaneously. Others wait until one is returned.
 *
 * This is a classic real-world semaphore use case — controlling access
 * to a fixed pool of resources where any thread can "check in" a resource.
 */
public class DatabaseConnectionPool {

    private static final int MAX_CONNECTIONS = 3;

    // Semaphore initialized with the number of available permits (connections).
    // fair=true means threads acquire in arrival order — prevents starvation
    // in production. Costs a bit of throughput due to the CLH queue overhead.
    private final Semaphore connectionPermits = new Semaphore(MAX_CONNECTIONS, true);

    // The actual pool of connection objects (simplified as strings here).
    private final Queue<String> availableConnections = new ArrayDeque<>();

    public DatabaseConnectionPool() {
        for (int i = 1; i <= MAX_CONNECTIONS; i++) {
            availableConnections.add("Connection-" + i);
        }
    }

    /**
     * Borrows a connection from the pool, blocking if none are available.
     * The semaphore enforces that at most MAX_CONNECTIONS threads
     * hold a connection at any time.
     */
    public String borrowConnection(String workerName) throws InterruptedException {
        System.out.printf("[%s] Waiting for a connection... (permits available: %d)%n",
                workerName, connectionPermits.availablePermits());

        // acquire() decrements the permit count by 1.
        // If the count is already 0, this thread parks (blocks) here
        // until another thread calls release().
        connectionPermits.acquire();

        // synchronized only on the Queue access — the semaphore already
        // guarantees at most MAX_CONNECTIONS threads reach here at once.
        String connection;
        synchronized (availableConnections) {
            connection = availableConnections.poll();
        }

        System.out.printf("[%s] Acquired %s (permits remaining: %d)%n",
                workerName, connection, connectionPermits.availablePermits());
        return connection;
    }

    /**
     * Returns a connection to the pool.
     * NOTE: Any thread can call this — the semaphore has no concept of
     * ownership. This is by design for pool scenarios, but means you
     * must ensure callers return the correct connection object.
     */
    public void returnConnection(String workerName, String connection) {
        synchronized (availableConnections) {
            availableConnections.offer(connection);
        }
        // release() increments the permit count and wakes a waiting thread.
        // Crucially: this thread does NOT need to be the one that called acquire().
        connectionPermits.release();
        System.out.printf("[%s] Returned %s (permits now: %d)%n",
                workerName, connection, connectionPermits.availablePermits());
    }

    public static void main(String[] args) throws InterruptedException {
        DatabaseConnectionPool pool = new DatabaseConnectionPool();
        // 5 workers competing for 3 connections — 2 must always wait.
        ExecutorService executor = Executors.newFixedThreadPool(5);

        for (int workerId = 1; workerId <= 5; workerId++) {
            final String workerName = "Worker-" + workerId;
            executor.submit(() -> {
                try {
                    String conn = pool.borrowConnection(workerName);
                    // Simulate using the connection for some work.
                    Thread.sleep(200);
                    pool.returnConnection(workerName, conn);
                } catch (InterruptedException e) {
                    Thread.currentThread().interrupt();
                }
            });
        }

        executor.shutdown();
        executor.awaitTermination(10, TimeUnit.SECONDS);
        System.out.println("\nAll workers done. Pool permits: " + pool.connectionPermits.availablePermits());
    }
}

Priority Inversion, Deadlock and the Production Failures Nobody Warns You About

Priority inversion is one of the most famous real-world concurrency bugs. It famously caused the Mars Pathfinder to reset repeatedly in 1997. Here's the scenario: a low-priority thread L holds a mutex. A high-priority thread H needs that same mutex and blocks. Meanwhile, a medium-priority thread M runs freely because H is blocked. The net effect: M — the lowest-priority task — is effectively running at the expense of H, inverting the priority ordering. The fix is priority inheritance: the OS temporarily boosts L's priority to match H's so it finishes fast and releases the mutex. POSIX mutexes support this with PTHREAD_PRIO_INHERIT. Java's monitor locks do not implement priority inheritance — something to know if you're running hard real-time workloads on the JVM.

Deadlock with mutexes follows a predictable pattern: thread A holds lock 1 and waits for lock 2; thread B holds lock 2 and waits for lock 1. The fix is lock ordering: always acquire multiple locks in the same global order across all code paths. Document the order. Enforce it in code review.

With semaphores, the symmetric deadlock is less common but permit leaks are insidious: if a thread acquires a permit and exits without releasing it (due to an exception, a return statement, or a missed code path), the effective pool size shrinks permanently until restart. Always use try/finally.

import java.util.concurrent.locks.ReentrantLock;
import java.util.concurrent.TimeUnit;

/**
 * Demonstrates deadlock caused by inconsistent lock ordering,
 * then shows the fix: always acquire locks in a globally agreed order.
 *
 * Scenario: transferring money between two accounts requires locking both.
 * Naive approach deadlocks. Fixed approach uses consistent lock ordering.
 */
public class DeadlockDemoAndFix {

    static class Account {
        final int id;
        double balance;
        final ReentrantLock lock = new ReentrantLock();

        Account(int id, double balance) {
            this.id = id;
            this.balance = balance;
        }
    }

    /**
     * BROKEN: Lock order depends on argument order.
     * Thread 1 calls transfer(accountA, accountB, 50) -> locks A, then B.
     * Thread 2 calls transfer(accountB, accountA, 30) -> locks B, then A.
     * -> Classic deadlock.
     */
    static void transferBroken(Account from, Account to, double amount)
            throws InterruptedException {
        from.lock.lock();
        System.out.printf("[%s] Locked account %d, waiting for account %d...%n",
                Thread.currentThread().getName(), from.id, to.id);
        Thread.sleep(50); // exaggerate the race window for demo purposes
        to.lock.lock();
        try {
            from.balance -= amount;
            to.balance   += amount;
        } finally {
            to.lock.unlock();
            from.lock.unlock();
        }
    }

    /**
     * FIXED: Lock order is determined by account ID — a global invariant.
     * Regardless of argument order, we always lock the lower-ID account first.
     * Both threads now agree on ordering -> deadlock is impossible.
     *
     * Uses tryLock() with timeout as an additional safety net.
     */
    static boolean transferFixed(Account first, Account second, double amount)
            throws InterruptedException {

        // Enforce consistent global lock ordering by account ID.
        Account lockFirst  = first.id < second.id ? first  : second;
        Account lockSecond = first.id < second.id ? second : first;

        // tryLock with timeout: fail fast rather than wait forever.
        // In production, you'd retry or surface an error to the caller.
        if (!lockFirst.lock.tryLock(1, TimeUnit.SECONDS)) {
            System.out.printf("[%s] Could not acquire lock on account %d — aborting transfer.%n",
                    Thread.currentThread().getName(), lockFirst.id);
            return false;
        }
        try {
            if (!lockSecond.lock.tryLock(1, TimeUnit.SECONDS)) {
                System.out.printf("[%s] Could not acquire lock on account %d — aborting transfer.%n",
                        Thread.currentThread().getName(), lockSecond.id);
                return false;
            }
            try {
                // We now hold BOTH locks safely.
                first.balance  -= amount;
                second.balance += amount;
                System.out.printf("[%s] Transfer of %.2f complete. Balances: A=%.2f, B=%.2f%n",
                        Thread.currentThread().getName(), amount, first.balance, second.balance);
                return true;
            } finally {
                lockSecond.lock.unlock();
            }
        } finally {
            lockFirst.lock.unlock();
        }
    }

    public static void main(String[] args) throws InterruptedException {
        Account accountA = new Account(1, 500.0);
        Account accountB = new Account(2, 300.0);

        System.out.println("=== Testing FIXED transfer (no deadlock) ===");

        Thread thread1 = new Thread(() -> {
            try { transferFixed(accountA, accountB, 50.0); }
            catch (InterruptedException e) { Thread.currentThread().interrupt(); }
        }, "Thread-1");

        Thread thread2 = new Thread(() -> {
            try { transferFixed(accountB, accountA, 30.0); }
            catch (InterruptedException e) { Thread.currentThread().interrupt(); }
        }, "Thread-2");

        thread1.start();
        thread2.start();
        thread1.join();
        thread2.join();

        System.out.printf("Final — Account A: %.2f, Account B: %.2f%n",
                accountA.balance, accountB.balance);
    }
}

Performance Trade-offs: When to Use Mutex vs Semaphore in Production

Choosing between a mutex and a semaphore isn't just about semantics — it has real performance consequences. Mutexes are designed for short critical sections where contention is low. They use the futex trick: in the uncontested case, just an atomic CAS. Under contention, a syscall is made, which is expensive — but the assumption is that most of the time there's no wait.

Semaphores, on the other hand, have an additional cost: each acquire and release involves AQS state management. The CLH queue of waiters adds overhead even when there's no contention because the algorithm checks state and queues. In practice, a semaphore is about 10-20% slower than a mutex for uncontended operations.

But here's the important part: semaphores shine when you need to control concurrent access to a limited set of resources — like a database connection pool. Using a mutex for that would be awkward: you'd need a counter and a condition variable. Semaphores provide that out of the box.

For signaling between threads, semaphores are the right choice. Mutexes with condition variables work, but they're more complex and error-prone. A semaphore is a one-liner: producer calls release, consumer calls acquire.

The bottom line: use mutexes for mutual exclusion, semaphores for resource pools and signaling. Don't try to use one for the other's job — it'll cost you performance and correctness.

Decision Framework: Which One Should You Actually Use?

Let's cut through the theory. Here's a decision process to apply in code review or design:

Ask yourself: What's the real problem? 1. Mutual exclusion - I need to ensure only one thread executes this block of code. -> Use a mutex (ReentrantLock or synchronized). 2. Resource pool - I have N identical resources (connections, sockets, buffers) and want to limit access to N threads. -> Use a semaphore. 3. Signaling - Thread A needs to tell thread B that a resource is ready, or a condition is met. -> Use a semaphore (or Condition with a mutex, but semaphore is simpler). 4. Reader-writer pattern - Many readers, few writers. -> Use ReadWriteLock (which is a mutex variant). 5. One-shot event - One thread needs to wait for another to complete a task exactly once. -> Use CountDownLatch or Semaphore(1).

If you find yourself writing a mutex but then using a separate counter to limit concurrency, you probably wanted a semaphore. If you find yourself using a semaphore to protect a critical section and ensuring the same thread always releases, you probably wanted a mutex (and you'll need to enforce ownership manually — risky).

In system design interviews, always clarify the ownership requirement. If the resource owner needs to release, it's a mutex. If any component can release (like a connection pool's return method), it's a semaphore.

This framework works for Java, C++, Python, and even database transaction schemas.

The Misconception That Eats Your Weekend — Mutex vs Binary Semaphore

Most devs treat binary semaphores and mutexes as interchangeable. They are not. The difference is ownership, and it will wreck your system if you ignore it.

A mutex has an owner. The thread that locks it must unlock it. A binary semaphore has no owner — any thread can post to it, any thread can wait on it. That sounds like a minor detail until your cleanup thread signals a semaphore that a worker thread is waiting on, and suddenly two threads are writing to the same socket.

Binary semaphores are for signaling. Producer-consumer patterns. Notify when a buffer is ready. Mutexes are for mutual exclusion. Guard a shared structure. The kernel enforces ownership on mutexes — if Thread A locks a mutex, only Thread A can unlock it. Semaphores don't care. They just count.

I've seen teams swap a mutex for a binary semaphore thinking they were the same thing. The result: corrupted state, heisenbugs, and a Monday morning firefight. Don't make that mistake.

// io.thecodeforge — cs-fundamentals tutorial

import threading
import time

shared_counter = 0
mutex = threading.Lock()

# Correct: mutex used for mutual exclusion
def safe_increment():
    global shared_counter
    for _ in range(1000):
        with mutex:
            shared_counter += 1

# Simulating a binary semaphore misuse
semaphore = threading.Semaphore(1)

def unsafe_increment():
    global shared_counter
    for _ in range(1000):
        semaphore.acquire()
        # No ownership — another thread can release before this thread finishes
        shared_counter += 1
        semaphore.release()

threads = [threading.Thread(target=safe_increment) for _ in range(10)]
for t in threads: t.start()
for t in threads: t.join()
print(f"Final counter with mutex: {shared_counter}")

# Reset for semaphore demonstration
shared_counter = 0
threads = [threading.Thread(target=unsafe_increment) for _ in range(10)]
for t in threads: t.start()
for t in threads: t.join()
print(f"Final counter with binary semaphore: {shared_counter}")

Semaphore Operations — Wait and Signal in the Trenches

Every semaphore is just an integer with two atomic operations: wait() and signal(). wait() decrements the counter. If the result is negative, the caller blocks. signal() increments. If the counter was negative, it wakes a waiter.

That's it. No magic. No fairness guarantees by default. The kernel maintains a queue of blocked threads, but the order they wake depends on the scheduler. Don't assume FIFO unless you configured it explicitly.

The counter value tells you the state: positive means resources available, zero means all in use, negative means pending waiters. Counting semaphores let you manage a pool of identical resources — think connection pools, thread pools, request slots.

In production, you must handle the edge case: a signal() during cleanup while waiters are still waking. That's why proper patterns pair semaphores with a flag indicating shutdown. Or you use a mutex + condition variable, which gives finer control. But for simple throttling, semaphores are hard to beat.

Monitor the semaphore counter in production. If it stays negative, you have leaky releases. If it spikes positive, waiters are starving. Both are bugs.

// io.thecodeforge — cs-fundamentals tutorial

import threading
import time

# Pool of 3 database connections
connection_pool = threading.Semaphore(3)

def query_database(client_id):
    print(f"Client {client_id}: waiting for connection...")
    connection_pool.acquire()
    print(f"Client {client_id}: acquired connection")
    time.sleep(0.5)  # simulate work
    connection_pool.release()
    print(f"Client {client_id}: released connection")

# Simulate 10 clients contending for 3 slots
threads = []
for i in range(10):
    t = threading.Thread(target=query_database, args=(i,))
    threads.append(t)
    t.start()

for t in threads:
    t.join()

print("All queries completed.")

The Spurious Wakeup Ambush — Why Your Semaphore Loop Needs a Second Look

You wrote a beautiful semaphore-based producer-consumer. It passes every unit test. Then under load, consumers wake up to an empty queue and crash. That's a spurious wakeup — the operating system lied to you. Wait (or P) returned, but the resource wasn't available. Happens on Linux, macOS, and especially in virtualized environments. The fix is dead simple: always wrap your semaphore wait in a while loop that rechecks the actual condition. Never assume the signal meant "go" — treat it as "maybe go, check first." This isn't a theoretical edge case. It's a production reality that sinks microservices when traffic spikes. POSIX explicitly permits spurious wakeups from condition variables and semaphores. Your loop is cheap. Your crash is expensive. Wrap it.

// io.thecodeforge — cs-fundamentals tutorial

import threading
import time
import random

queue = []
sem = threading.Semaphore(0)
mutex = threading.Lock()

def consumer():
    while True:
        sem.acquire()  # may wake up spuriously
        with mutex:
            if queue:  # MUST recheck
                item = queue.pop(0)
                print(f"Consumed: {item}")
        time.sleep(random.uniform(0.1, 0.3))

# Producer adds items and signals sem
# Consumer only acts if queue is non-empty after acquire

The Two-Resource Deadlock That Will Make You Question Your Architecture

You have two semaphores protecting two resources. Thread A grabs semaphore 1, thread B grabs semaphore 2. They both wait for the other. You're deadlocked. This is the classic dining philosophers trap, but it shows up in real systems: connection pools, database handles, lock hierarchies. The fix isn't "be careful" — that's cargo cult nonsense. You need a consistent ordering policy. Always acquire semaphores in the same global order. If that's impossible, use a try-and-backoff pattern. The senior move: build a lock hierarchy into your system design. Document it. Enforce it in code reviews. When you see two semaphores in a function, your brain should scream "deadlock risk." The worst part? It only shows up under specific interleavings. You can run for weeks before it bites you. And it always bites at 3 AM.

// io.thecodeforge — cs-fundamentals tutorial

import threading
import time

sem_a = threading.Semaphore(1)
sem_b = threading.Semaphore(1)

def worker_ab():
    sem_a.acquire()
    time.sleep(0.01)  # window for deadlock
    sem_b.acquire()
    print("Worker AB got both")
    sem_b.release()
    sem_a.release()

def worker_ba():
    sem_b.acquire()
    time.sleep(0.01)  # reverse order = deadlock city
    sem_a.acquire()
    print("Worker BA got both")
    sem_a.release()
    sem_b.release()

t1 = threading.Thread(target=worker_ab)
t2 = threading.Thread(target=worker_ba)
t1.start()
t2.start()
t1.join()
t2.join()

print("This never prints if deadlocked")

The Critical-Section Problem — Why Your Data Gets Corrupted

Concurrency boils down to one question: what happens when two threads write to the same variable at the same time? That shared resource is your critical section. The problem isn't the code inside it — it's that without protection, the operating system can pause thread A mid-write, swap in thread B, and let B corrupt A's partial result. A critical section has three characteristics: mutual exclusion (only one thread touches it at a time), progress (if no thread is inside, someone gets in), and bounded waiting (no thread starves forever). These three criteria are the litmus test for every mutex and semaphore implementation you'll ever write. If your lock violates any of them, you have a bug. If your trading engine violates bounded waiting, you get infinite latency on a single order. Understand these rules before you touch a single lock.

// io.thecodeforge — cs-fundamentals tutorial

import threading

shared_counter = 0

def unsafe_increment():
    global shared_counter
    # No protection — critical section exposed
    temp = shared_counter
    # OS can swap threads here
    shared_counter = temp + 1

threads = [threading.Thread(target=unsafe_increment) for _ in range(100)]
for t in threads: t.start()
for t in threads: t.join()
# Expected 100, often less
print(f"Corrupted value: {shared_counter}")

Semaphore vs Mutex — The Core Difference That Decides Your Lock Choice

Every engineer knows semaphores count and mutexes lock. The real difference is ownership. A mutex remembers which thread locked it. Only that thread can unlock it. A semaphore has no memory of who requested a resource — any thread can signal, any thread can wait. This matters when you build a resource pool. Use a mutex to protect a single shared bank balance — you need to know the thread that deducted money is the same one that deposits it. Use a semaphore to limit connections to a database pool — you don't care which thread returns a connection, as long as the count is correct. The ownership rule breaks trading engines: if thread A acquires a mutex, then a higher-priority thread B tries the same lock, priority inversion freezes the system. With a semaphore, no thread owns anything, so there's no inversion — but you lose the safety of guaranteed release. Choose ownership only when you need it.

// io.thecodeforge — cs-fundamentals tutorial

import threading

# Mutex: ownership enforced
mutex = threading.Lock()
mutex.acquire()
# Only this thread can release
try:
    pass
finally:
    mutex.release()

# Semaphore: no ownership
sem = threading.Semaphore(1)
sem.acquire()
# Any thread can release — can break invariants
sem.release()  # Legal, but may signal wrong resource