MKOBAA
Home
← Back to selected work

CASE STUDY · 1337 / 42 validated project

Philosophers

A concurrency simulation based on the Dining Philosophers problem.

Role
1337 / 42 Developer
Access
1337 / 42 validated project
[01]

Context

A concurrency simulation based on the Dining Philosophers problem. The implementation coordinates worker threads, shared forks, timing, completion, and shutdown while preventing data races and deadlocks.

[02]

My responsibility

Built and validated through the 1337 / 42 project curriculum, with direct responsibility for implementation, debugging, testing, and evaluation requirements.

[03]

System scheme

Engineering scheme

Concurrent philosopher lifecycle

Input → Processing → Output

Worker threads share fork resources while synchronized state and timing checks prevent races, deadlocks, and inconsistent output.

  1. 01

    Argument validation

    Validate population, timing, and optional meal target.

  2. 02

    Shared resources

    Create fork mutexes and synchronized simulation state.

  3. 03

    Worker threads

    Run think, acquire, eat, release, and sleep cycles.

  4. 04

    Fork ordering

    Apply a consistent acquisition strategy to avoid deadlock.

  5. 05

    Monitor

    Check starvation and completion against synchronized timestamps.

  6. 06

    Shutdown

    Stop workers, serialize final output, and release resources.

Mutex discipline
Timing accuracy
Deadlock avoidance
Race detection
[04]

Implementation breakdown

  1. 01

    System design

    POSIX threads represent philosophers, while mutexes protect shared forks, state, and synchronized output.

[05]

Technical scope

C01
POSIX Threads02
Mutexes03
[07]

Implementation details

  • ✓Argument validation: Validate population, timing, and optional meal target.
  • ✓Shared resources: Create fork mutexes and synchronized simulation state.
  • ✓Worker threads: Run think, acquire, eat, release, and sleep cycles.
  • ✓Fork ordering: Apply a consistent acquisition strategy to avoid deadlock.
  • ✓Monitor: Check starvation and completion against synchronized timestamps.
  • ✓Shutdown: Stop workers, serialize final output, and release resources.
[08]

Engineering constraints

  • →Preventing data races while keeping timing checks accurate.
  • →Avoiding excessive polling and unnecessary CPU usage.

Need a system like this?

Tell me about the workflow, integration, or backend problem.

Discuss a project