Two students book the last seat at the same instant
Both threads check the seat count, both see one left, both book it. The cinema has now sold seat 14 twice. This session shows that happening on a real booking screen, then fixes it with one keyword.
This session has not been authored yet
You have reached a real page, but an empty one. The deck for Class 23 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-23 openerThe hook: the same seat, sold twice, by a program with no bugs in it.
- What a race condition isShared state plus unlucky timing — and why it is invisible most of the time you run it.
- The seat-booking screensA real movie-ticket seat map: two bookings click the same seat, and the counter goes wrong on screen.
- Why check-then-act breaksThe gap between reading the count and updating it, drawn out instruction by instruction.
- synchronized methodsOne lock, one thread at a time —
bookTicket()before and after, side by side. - synchronized blocksLocking the smallest thing that needs locking, instead of the whole method.
- volatileVisibility, not atomicity — the distinction that the exam and interviews both probe.
- PYQ · P2·Q3Why synchronization matters in multithreading, answered in full with the seat-booking program.
- Activities + close cardBreak it, watch it fail, fix it — then the runway into
wait()andnotify().
Seat-locking, shown on screen
This session and Lab 5 both use real movie-ticket seat-booking screens — you click a seat, watch the lock get taken, and see what happens when a second booking clicks the same seat a millisecond later. The race is demonstrated visually before a single line of theory is defended.