← cd ~
~/42-firenze/codexion
42 firenze · milestone 3 · c
Codexion
A concurrency problem in the spirit of the dining philosophers. N coders sit around a table with one USB dongle between each pair. A coder needs both neighbouring dongles to compile, and burns out if too much time passes since their last compile. Every coder is a POSIX thread. Every dongle is a mutex with a condition variable, and a hand-written priority queue decides who gets a released dongle first.
log
dongle free
coder holds it, waiting for the second one
coder holds both: compiling
just released, cooling down
coder ring = time since last compile
timeline · click or drag to scrub
waitingholding one donglecompilingdebuggingrefactoringburnout
Two real runs with identical parameters, replayed: . With EDF every coder finishes; with FIFO one burns out. Thread timing varies, so every run is different. The log only says "has taken a dongle": the dongle ids come from the code, where coder i owns dongles i and i+1 and always locks the lower one first.
how it works
- Deadlock: dongles are always acquired in a fixed order, which breaks the circular-wait condition.
- Fairness: each dongle has a priority queue, a binary min-heap written from scratch. FIFO orders by arrival time; EDF orders by
last_compile + time_to_burnout, so the coder closest to burning out goes first. - Same parameters, different outcome: in the replay above, the FIFO run lets a coder wait behind neighbours who arrived earlier until it burns out. EDF serves the closest deadline first, and everyone finishes.
- Burnout detection: a separate monitor thread checks every deadline and, when one is missed, stops the simulation and wakes every waiting thread.
- Shared state: dongles and the log are both behind mutexes, so output lines never interleave. The build runs clean under ThreadSanitizer.