This project has been created as part of the 42 curriculum by nkojima.

Description

Philosophers is the mandatory threading exercise from the 42 curriculum. The philo program simulates the dining philosophers problem: each philosopher runs in its own thread, shares forks with neighbors, and must eat, sleep, and think without data races, deadlocks, or incorrect death detection.

Each philosopher repeatedly takes two forks, eats, sleeps, and thinks. A separate monitor thread checks whether a philosopher has gone too long without starting a meal and stops the simulation on death or when every philosopher has eaten enough times (optional fifth argument). Forks are protected with mutexes; philosophers reserve both forks before locking them, then acquire the mutexes in a fixed order to avoid deadlock.

Instructions

Build

make -C philo

Run

./philo/philo number_of_philosophers time_to_die time_to_eat time_to_sleep \
  [number_of_times_each_philosopher_must_eat]

Examples:

./philo/philo 5 800 200 200
./philo/philo 5 800 200 200 7
./philo/philo 1 800 200 200

Tests

make -C philo test
make -C philo norm

Resources

• Philo project notes (Zenn) — threads, mutexes, deadlock, and common eval scenarios
• (outdated) What was philosopher? (Qiita) — Coffman conditions, deadlock prevention vs avoidance, starvation (legacy subject)
• Dining philosophers problem (Wikipedia, JA) — classic problem statement and solutions (hierarchy, waiter, Chandy/Misra)
• Slides: understanding Philosophers (Google) — 42-oriented overview
• Tsukuba CS lecture (2020-05-08) — concurrent systems course notes
• Concurrent vs parallel processing (Qiita) — process vs thread, concurrent vs parallel terminology
• Dining philosophers deadlock in C (Qiita) — deadlock demo and ordered fork acquisition
• Threads/processes vs concurrent/parallel (Zenn) — why these concepts should not be conflated
• Project subject: en.subject.pdf in this repository
• Internal design notes: docs/design.md (Japanese)

How AI was used

AI tools (Cursor / Claude) were used for:

• Drafting and refining docs/design.md (mutex layout, lock order, test matrix)
• Reviewing concurrency and subject compliance on feature branches
• Designing fork reservation and turn-based scheduling to stabilize no-death test cases
• README and wording review

All simulation logic, mutex layout, and final code were written and verified by the author (build, unit tests, and manual scenario runs).