The project consists of implementing, in user space and using Rust, a custom library called mypthreads that replaces a subset of the functionality of pthreads in GNU/Linux. The idea is that you do not touch the kernel, but instead build a “simulated” thread subsystem on top of the operating system, in order to understand how scheduling, concurrency handling, and synchronization primitives work. This library cannot delegate to real pthreads nor to high-level Rust abstractions such as std::thread or std::sync::Mutex for the evaluated logic: the intention is that you directly control thread creation, context switching, blocking, and unblocking at user level. Within mypthreads you must reimplement the basic thread and mutex functions (create, terminate, yield, join, detach, initialize and manage mutexes) and also add an extra function: my_thread_chsched, which allows you to change the type of scheduler associated with a thread at runtime. Each thread, at the moment it is created with my_thread_create, must be able to receive the type of scheduler it will use and its specific parameters. If nothing is specified, the default scheduler is Round Robin. The library must support at least three policies: Round Robin, Lottery, and Real-Time, each with its own behavior and possible additional parameters (for example, number of “tickets” in Lottery or deadlines/time limits in Real-Time). The simulated city, ThreadCity, is the scenario where your thread library is put to the test. It is modeled as a grid of at least 25 blocks, with outer streets that close the traffic mesh and a river that divides the city into a northern and a southern zone. Three bridges connect both zones and act as critical bottlenecks in vehicle circulation. Inside the blocks there are shops that serve as destinations for the inhabitants, and at least two nuclear plants are added, which depend on a regular supply of resources in order not to explode. This map is not only visual: it defines the topology through which the thread-vehicles move. In the simulation, different types of mobile entities are generated: “normal” cars, ambulances, trucks that transport water or radioactive material, and boats that navigate the river. The creation of these vehicles is random over time, and each one must also randomly choose a valid origin and destination within the city, such that not all depart from or arrive at the same place. It is required that, throughout the simulation, at least 25 cars be generated, and that arrivals follow some reasonable probabilistic process (for example, Normal or Poisson), which you must document. A strong requirement is that there be no collisions: your concurrency logic and your map representation must prevent two vehicles from occupying the same cell at the same time. The bridges have differentiated behaviors that affect both traffic logic and thread scheduling decisions. Bridge 1 is single-lane and is controlled by traffic lights at the entrance and the exit; Bridge 2 is also single-lane, but instead of traffic lights it has a yield sign at one of its ends. Bridge 3 has two lanes, but it has the particularity that it opens (or is “deactivated”) to allow boats to pass: when vessels arrive, the bridge becomes unusable for land vehicles for a period. Although the boats operate in the area of Bridge 1 and their dock is located between it and Bridge 2, the bridge that “opens” and blocks traffic is Bridge 3, according to the clarifications. The traffic control system includes traffic lights that only handle green and red states, with no yellow light, and whose timings you must define and scale to the speed of the simulation. Ambulances have absolute priority: they should not get stuck at traffic lights nor be penalized compared to other vehicles when crossing bridges. In practice, this implies that your scheduling and synchronization model must treat ambulances as high-priority threads, ensuring that their passage is not unjustifiably delayed when they compete for shared resources such as bridges or road segments. The nuclear plants introduce the critical real-time part of the simulation. These plants require periodic deliveries of water and radioactive material, carried out by trucks that must arrive before a given deadline, which is modeled as a pseudo-random value within a documented range. The threads representing these trucks must be scheduled with the Real-Time policy; if they do not reach their destinations before their deadline, the plant or the truck “explodes” and this is considered a system failure. After an explosion, a new plant or a new truck must be generated so that the simulation continues, in such a way that the real-time scenario remains running continuously. To improve the chances of success for these deliveries, the system can temporarily raise the priority of critical threads using my_thread_chsched, for example by migrating them to a Lottery scheduler with more “tickets” or to some more favorable configuration. In this way, the project not only asks you to implement the schedulers, but also to use them intelligently to meet real-time constraints in a congested environment with shared resources. This game of changing scheduling policies and parameters on the fly is one of the key points in the practical understanding of scheduling algorithms. Finally, the simulation must be visualized through an animation implemented with the GTK library, clearly showing the city, the vehicles, the bridges, the boats, and the plants. From the administrative point of view, you must deliver the source code in Rust, the binary compiled for x86 architecture, and documentation in LaTeX converted to PDF, following the indicated format. The evaluation is distributed among the correct implementation of mypthreads and its schedulers, the behavior of ThreadCity (ambulances, bridges, cars, nuclear plants, animation), and the quality of the documentation. If you use real pthreads, if the program does not compile, or if you break critical submission rules, the grade is automatically 0, so robustness and discipline in development are an essential part of the project.