UCT CSC2002 / 2023
The concurrent club
A graphical club simulation exploring admission, grid movement, shared counters and thread coordination.
UCT / COURSE CONTEXT / 2023
CSC2002S · Computer Science 2002
Concurrent programming, computer architecture and interface design, with Java and assembler practicals.
2026 PORTFOLIO RECREATIONS
A club at capacity
ENGINEERING PERSPECTIVE
Inside the work
Make shared-state coordination visible through a club simulation. Admission, occupied cells and counters reveal why synchronized access and liveness are separate concerns.
- Java threads / atomic variables
- Patrons move and update shared occupancy/counter state.
- Swing
- The original source-built grid, bar and controls display the evolving simulation.
Coordinate entry
Start/pause flags and admission conditions govern arriving patrons.
- Mutual exclusion
- Two patrons must not claim the same grid location through a race.
- Capacity and admission
- Checking a limit and admitting a patron must be coordinated, not merely counted.
- Liveness and UI safety
- Compilation does not prove deadlock freedom; monitor ownership and the Swing event-dispatch thread need review.
What the demonstration establishes
The actual old GUI was compiled and captured. The new browser club explanation is separate; it does not establish that the original busy-wait/monitor code is race-free.
Evidence behind this page
Individual named report on attributed teaching scaffolding and authentic recovery screenshot. An attempted barman extension is not a completed feature.
How it works
Each patron has a thread and a grid location. Grid blocks coordinate occupancy, atomic counters track waiting/inside/left patrons, and Swing displays the changing grid. The main application exposes Start, Pause and Quit.
Results & recovery
- Eight recovered Java classes compile with JDK 17.
- The actual Swing interface was launched from a clean source copy during the 2026 recovery.
Technical limitations
Compilation and a screenshot do not establish deadlock freedom. Busy-wait loops and a notifyAll call without the matching monitor remain in the submitted source. The console Andre scheduler is a separate 2024 project.
What I would improve now
Use blocking admission primitives, review lock ownership and capacity check atomicity, add liveness tests and update Swing widgets on the event-dispatch thread.