Quickstart
After building the project, run the simulation with the required parameters:Basic Examples
Understanding the Output
The program outputs timestamped philosopher actions in the following format:Example Output
Output Actions
The simulation logs the following actions:has taken a fork- Philosopher picks up a fork (logged twice per philosopher)is eating- Philosopher begins eatingis sleeping- Philosopher begins sleepingis thinking- Philosopher begins thinkingdied- A philosopher has died from starvation
The timestamp represents milliseconds elapsed since the simulation started. All timestamps are relative to the start time.
Simulation Behavior
Normal Execution
When parameters are set correctly:- Philosophers alternate between eating, sleeping, and thinking
- Each philosopher needs two forks to eat
- Forks are shared between adjacent philosophers
- The simulation continues until a philosopher dies or all complete their meals (if the optional parameter is provided)
Completion Scenarios
The simulation ends when:- A philosopher dies: If any philosopher doesn’t eat within
time_to_diemilliseconds since their last meal - All philosophers finish eating: If the optional meal count parameter is provided and all philosophers eat that many times
Edge Cases
With a single philosopher, there’s only one fork available. The philosopher will take one fork and wait for a second fork that never becomes available, eventually dying after
time_to_die milliseconds.Example Terminal Sessions
Successful Simulation with Meal Limit
Philosopher Dies
Common Usage Patterns
Testing for Deadlock
Use tight timing to test if the implementation avoids deadlock:Testing Race Conditions
Use many philosophers to stress-test thread synchronization:Verifying Correctness
Use a small meal count to verify all philosophers get equal opportunity:The program uses mutexes to protect shared resources (forks) and prevent race conditions. Output messages are also protected by a mutex to prevent interleaved text.