How a Deadlock Traps an Application
A thread is a sequence of instructions a program can run independently of its other work. To coordinate those threads, software often makes them wait for shared resources—such as a lock that protects data from being changed simultaneously.
A deadlock occurs when the waiting forms a closed loop. Imagine Thread A has locked Resource 1 and requests Resource 2, while Thread B has locked Resource 2 and requests Resource 1. Each thread is waiting for the other to release what it holds. Because neither can continue, neither reaches the code that would release its lock.
Why the Program Can Look Completely Frozen
The operating system can schedule threads that are ready to run, but scheduling cannot help a thread blocked on a lock. If the threads responsible for responding to clicks, drawing a window, or handling a network request are caught in the same deadlock, the application may stop responding even though the computer itself is still running.
The trouble can be hard to reproduce. The threads must reach the conflicting requests in a particular order, and small timing differences can determine whether that order occurs. A program may work many times before a rare sequence of events leaves it stuck.
Breaking the Cycle
Developers can prevent common deadlocks by requiring threads to acquire locks in a consistent order: if every thread requests Resource 1 before Resource 2, the two-thread cycle cannot form. Other approaches include limiting how long a thread waits or avoiding a lock when it is already held by another thread, then retrying later.
These safeguards involve tradeoffs: retries can waste work, and lock-order rules require care as software grows. But a single consistent ordering can turn a system in which each thread guards the key the other needs into one where both can eventually finish.
