Locks, Mutexes, Semaphores, & Spinlocks

Synchronization primitives allow multiple threads or processes to coordinate access to shared hardware, memory, or network resources. Choosing the wrong locking primitive can destroy system scalability, causing massive latency spikes or thread starvation under load.

The four primary synchronization primitives in production systems:

1. Mutex (Mutual Exclusion Lock): Grants exclusive, single-thread access to a critical section. If Thread A holds the mutex, any other thread attempting to acquire it is put to sleep by the OS scheduler until Thread A releases it.
2. Read-Write Lock (RWLock / Shared-Exclusive Lock): Allows concurrent, unlimited readers to access a resource simultaneously, but requires exclusive single-threaded access for writers.
3. Counting Semaphore: Maintains an integer counter representing a pool of available permits (e.g., maximum 50 concurrent database connections). Threads increment permits on release and decrement on acquire, sleeping when the count hits zero.
4. Spinlock: A busy-waiting lock where the waiting thread repeatedly executes a CPU loop (PAUSE instruction / CAS) without yielding to the OS scheduler. Extremely fast (~10-50ns) if the critical section is ultra-short, but burns 100% CPU on long waits.

In modern Linux systems, mutexes are implemented using Futexes (Fast Userspace Mutexes).

Historically, acquiring a lock required invoking a kernel system call every single time (~1-2μs). Futexes revolutionize this:

• Uncontended Fast Path (User Space): When Thread A acquires an uncontended lock, it executes a single hardware atomic CAS instruction (LOCK CMPXCHG) in User Space (~15ns) with zero kernel overhead.
• Contended Slow Path (Kernel Space): Only if the CAS fails (another thread already holds the lock) does the thread execute the futex(FUTEX_WAIT) system call, entering the kernel to sleep on a wait queue.
• Unlock: The releasing thread atomically clears the lock flag and calls futex(FUTEX_WAKE) only if waiting threads are present.

In read-heavy workloads (e.g., an in-memory configuration registry, DNS cache, or product catalog with a 99:1 Read:Write ratio), standard mutexes serialize all reads unnecessarily.

An RWLock provides two lock modes:

• RLock() / RUnlock(): Shared read lock. Hundreds of threads read concurrently.
• Lock() / Unlock(): Exclusive write lock. Blocks all readers and writers.

The Writer Starvation Vulnerability: If new readers continuously arrive and acquire shared read locks before existing readers finish, the waiting writer thread may starve indefinitely, never getting an opportunity to update the data. Solution: Production RWLocks (e.g., pthread_rwlock_t with PTHREAD_RWLOCK_PREFER_WRITER_NP, Go sync.RWMutex) prioritize pending writers by blocking subsequent new readers once a writer enters the queue.

package cache

import "sync"

type ThreadSafeCache struct {
	mu    sync.RWMutex
	items map[string]string
}

func (c *ThreadSafeCache) Get(key string) (string, bool) {
	c.mu.RLock()         // Multiple goroutines can read concurrently!
	defer c.mu.RUnlock()
	val, ok := c.items[key]
	return val, ok
}

func (c *ThreadSafeCache) Set(key string, val string) {
	c.mu.Lock()          // Exclusive lock: blocks all readers & writers during write
	defer c.mu.Unlock()
	c.items[key] = val
}