Locks, Mutex, Semaphore

The critical section

A critical section is any piece of code that reads and writes state shared with other threads — a counter, a list, a cache entry, a file handle, a bank balance. Its danger is not the code itself but the fact that a thread can be paused by the operating system between any two machine instructions. Your innocent balance++ can be interrupted right after the read and before the write, and another thread can slip in during that gap. You never get to choose when that happens, so you must make the gap impossible to exploit.

• Read — thread A loads balance (100) into a register.
• Modify — thread A computes 101 in its own registers. Meanwhile thread B also loads balance and still sees 100.
• Write — A stores 101. Then B stores 101 as well. Two increments happened; the counter moved by one. That is a lost update.

Mutex: acquire → work → release

A mutex has exactly two operations. acquire() (also called lock()) says "give me the key; if someone else has it, put me to sleep until it is free." release() (unlock()) hands the key back and wakes one waiting thread. Between those two calls, you are guaranteed to be alone. The critical rule is that the release must be unconditional — if your code throws an exception between acquire and release and you skip the unlock, the key is gone forever and every other thread blocks until the process is killed.

private final Lock lock = new ReentrantLock();
private int balance = 100;

void deposit() {
    lock.lock();              // acquire — blocks if someone else holds it
    try {
        balance = balance + 1;   // the critical section: read → +1 → write
    } finally {
        lock.unlock();        // release — ALWAYS, even if the body throws
    }
}

Every language spells that safety net differently, but it is always the same idea: tie the release to leaving the block, not to reaching a line of code. Java uses try/finally (or synchronized, which unlocks automatically). C++ uses std::lock_guard, whose destructor unlocks when the scope ends — that is RAII, resource acquisition is initialisation. Python uses with lock:. Go uses defer mu.Unlock() on the line right after mu.Lock(), so the two are impossible to separate by accident.

synchronized and reentrancy, in two lines

In Java, every object carries a built-in lock called its monitor. Writing synchronized (obj) { ... } acquires that object's monitor for the block, and marking a method synchronized locks this for the whole method — no explicit unlock needed, the JVM releases it when the block exits, even on an exception. Java's locks are also reentrant: the thread that already holds a lock can acquire it again without blocking itself (a counter goes up, and the lock is only truly free when it hits zero). That is what lets one synchronized method safely call another on the same object. Not every lock is reentrant, though — a plain POSIX mutex or a Go sync.Mutex will deadlock against itself if you lock it twice in the same goroutine.

Semaphore: a counter, not an owner

A semaphore holds an integer: the number of permits available. acquire() takes one permit and blocks while the count is zero; release() gives one back and wakes a waiter. Set it to 3 and three threads run inside the guarded region simultaneously. Two consequences of "it is only a counter" catch beginners out:

• There is no owner. A mutex remembers who locked it, and in most libraries only that thread may unlock it. A semaphore does not — any thread may call release(), even one that never acquired. That is a feature: it lets one thread signal another (a producer releasing a permit that a consumer is waiting on).
• A binary semaphore (1 permit) ≈ a mutex, but without ownership, and usually without reentrancy. It gives you mutual exclusion; it does not give you the safety checks or the "same thread must unlock" discipline of a real mutex. When you want mutual exclusion, use a mutex; use a semaphore when you want to cap how many.
• N > 1 permits is not mutual exclusion. A semaphore of 3 happily lets three threads corrupt the same counter together — exactly what the prototype shows. It limits concurrency; it does not make a critical section safe.

Blocking, tryLock and timeouts

A plain lock() blocks — the thread sleeps until the lock is free, however long that takes. Sometimes you would rather not wait forever: tryLock() returns false immediately if the lock is taken, and tryLock(200, MILLISECONDS) waits only as long as you allow, then gives up and returns false. Use them when you have something useful to do instead of waiting (serve a cached value, return "busy, try again", fail a request cleanly rather than piling up threads).

Reach for a mutex when...

• Two or more threads read and write the same state — a counter, a map, a cached object, a file. If even one thread writes, the access needs guarding.
• Several fields must stay consistent together — moving money between two accounts, updating an index and its list. Atomics fix one variable; a lock lets you keep an invariant.
• The guarded work is short — a handful of lines with no I/O, no waiting, no calls into code you do not control.

Reach for a semaphore when...

• You want to cap concurrency, not exclude it — at most 10 open database connections, 5 parallel uploads, 3 workers hitting a fragile downstream API.
• One thread needs to signal another — a producer release()s a permit that a waiting consumer acquire()s. A mutex cannot do this, because only the owner may unlock it.

Skip both when...

• Nothing is shared — thread-local or immutable data needs no lock at all. The cheapest synchronisation is not sharing.
• It is a single counter or flag — an atomic type is faster and cannot be forgotten to unlock.
• A higher-level tool already fits — a ConcurrentHashMap, a blocking queue, an actor, or a Go channel hides the locking and is much harder to get wrong.