Threads that talk to each other — and the ones that wait forever
Locking fixed the race. Now two threads each hold what the other needs, and both wait politely until the end of time. This session closes Unit 2 — including an honest teach-back of all four pillars, now that encapsulation is genuinely in hand.
This session has not been authored yet
You have reached a real page, but an empty one. The deck for Class 24 is planned in full in the course knowledge document and is queued for authoring — nothing on this page is finished teaching content.
The roster underneath is the actual plan for this session, so you can see exactly what will land here.
What this class will cover
- Class-24 openerFrom locking to talking — and to the failure mode locking creates.
- wait() and notify()How one thread hands control to another, and why these live on
Objectand not onThread. - Producer–consumerThe classic pairing, built and run — one side fills, the other drains, neither spins.
- notify() vs notifyAll()Waking one versus waking everybody, and the lost-wakeup bug that picks the wrong one for you.
- DeadlockThe classic two-lock standstill, reproduced deliberately so you can watch it happen.
- Preventing deadlockLock ordering, timeouts, and holding fewer locks — the practical rules.
- The honest four-pillar teach-backAbstraction, encapsulation, inheritance and polymorphism explained back properly, now that Unit 2 has filled the gaps Unit 1 left.
- Unit-2 close + Lab 5 runwayThe whole unit stitched into one revision map, then the seat-booking lab.
The end of Unit 2
After this class the unit has one thing left — Lab 5, where the movie-ticket counter gets raced by Diya's and Rohit's booking threads, overbooks on purpose, and is then provably fixed with synchronized.