Open this lesson in your favourite AI. It'll walk you through the why, explain the demo, and quiz you on the try-it list.
The dining philosophers problem is the canonical illustration of deadlock, and understanding it pays off every time you hold two locks at once. Five philosophers at a circular table each need both neighboring forks to eat, but there's only one fork between each pair. When all five reach for the fork on their left simultaneously, everyone holds one fork and waits for the fork on their right — and nobody eats, forever. The real-world version is any situation where two threads each hold a lock the other needs: thread A holds lock 1 and waits for lock 2, thread B holds lock 2 and waits for lock 1. Recognizing the dining philosophers pattern in real code is the first step to preventing it.
Five philosophers sit around a circular table. Between each pair there is one fork. A philosopher needs both neighboring forks to eat. They all reach left at the same instant.
Everyone is holding one fork, waiting for the one on their right. Nobody eats. Nobody puts a fork down. The system is frozen. This is a deadlock.
Don't implement it yet — just let the picture sink in. We'll revisit in the Deadlocks module.
Use these three in order. Each builds on the one before.
Give me the dining philosophers problem in one paragraph suitable for a smart non-programmer. No code.
Map the dining philosophers problem onto Coffman's four conditions for deadlock. Which condition corresponds to which part of the scenario?
List three practical solutions (resource ordering, a waiter/arbiter, try-with-timeout) with tradeoffs. Which would I pick for a small number of philosophers vs. 10,000?