🧵 Codexion - Resource Synchronization Challenge

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

---

📑 Table of Contents

• About the Project
• Features
• Compilation & Usage
• How It Works
• Simulation
• Blocking Cases Handled
• Thread Synchronization Mechanisms

---

🏫 About the Project

Codexion is a concurrency challenge that models a shared co-working environment where coders compete for limited resources—rare USB dongles—to compile quantum code. Based on the classic Dining Philosophers problem, this simulation requires multiple threads to coordinate access to shared mutexes without causing deadlocks, starvation, or "burnout".

The project emphasizes mastery of POSIX threads, mutexes, and advanced scheduling algorithms (FIFO and EDF).

The project is written in accordance with the 42 Norm, ensuring clean, readable, and maintainable code.

Peer-graded at 42Barcelona with a final grade of 100/100.

---

🚀 Features

• Multithreaded implementation using POSIX threads
• Resource Management: Each coder requires two dongles simultaneously to enter the "Compiling" state.
• Fair Arbitration: Implements two scheduling policies—First In, First Out (FIFO) and Earliest Deadline First (EDF).
• Real-time Monitoring: A separate monitor thread detects burnout with high precision (within 10ms).
• Precise synchronization with mutexes (and controlled shared state)
• Deterministic behavior under strict timing constraints
• Clean thread lifecycle management (creation, execution, termination)
• Robust error handling during initialization and runtime
• Memory-safe execution (no leaks, no data races, no deadlocks) tested with valgrind and helgrind.

---

⚙️ Compilation & Usage

Prerequisites

• GCC or Clang compiler.
• POSIX-compliant operating system (Linux/macOS).

Compilation

Compile the project using the provided Makefile:

make

The Makefile includes the mandatory rules: $(NAME), all, clean, fclean, and re.

Execution

Run the executable with the following mandatory arguments:

./codexion number_of_coders time_to_burnout time_to_compile time_to_debug time_to_refactor number_of_compiles_required dongle_cooldown scheduler

Example:

./codexion 5 800 200 200 200 7 100 edf

---

🧠 How It Works

Codexion builds upon the core ideas of the Dining Philosophers problem while extending its logic:

• Each entity runs in its own thread
• Shared resources are protected using mutex locks
• Critical sections are kept minimal to reduce contention
• Global state is carefully guarded to avoid race conditions
• Threads check shared flags to allow graceful shutdown
• Timing logic ensures accurate simulation and prevents starvation

Special care is taken to:

• Avoid deadlocks
• Prevent busy-waiting where possible
• Ensure predictable behavior even under high contention

The project emphasizes correctness first, then performance, mirroring real-world concurrent system design principles.

---

🎮 Simulation

The simulation follows a strict lifecycle for each coder:

1. Requesting Dongles: The coder attempts to acquire their left and right dongles.

2. Compiling: Once both dongles are secured, the coder compiles for time_to_compile.

3. Debugging: After compiling, the coder releases the dongles and enters the debugging state.

4. Refactoring: Once debugging is complete, the coder refactors before attempting to compile again.

The simulation terminates if any coder "burns out" (fails to start compiling before the time_to_burnout deadline) or if all coders reach the number_of_compiles_required.

🚫 Blocking Cases Handled

• Deadlock Prevention: Implemented through asymmetric resource acquisition (odd/even ordering) to break the circular wait condition.

• Starvation: Prevented by the EDF scheduler, which prioritizes coders closest to their burnout deadline.

• Dongle Cooldown: Managed via timestamps to ensure a dongle remains unavailable for dongle_cooldown ms after release.

• Log Serialization: All output is protected by a global mutex to prevent message interleaving.

🔐 Thread Synchronization Mechanisms

• pthread_mutex_t: Used to protect individual dongle states and shared simulation data.

• pthread_cond_t: Utilized for efficient waiting queues, allowing threads to sleep until a dongle is available and its cooldown has expired.

• Custom Priority Queue (Heap): A manual implementation of a Min-Heap is used to handle the FIFO and EDF scheduling logic as required by the subject.