100 workers produce 10 cars given a reasonable amount of storage spaces in ~17.14 seconds.
This project has a companion technical report, learn more.
Pamuretas (Parallel Multi-Dependency Resource-Critical Task Scheduler) is a dynamic job allocation and dispatch system that is designed to be robust, flexible and efficient. Currently, it can only solve one particular instance of this class of problems, but it does it very well.
We formulate our problem as a variant to the classical costumer-producer problem with Resource Constrained Project Scheduling Problem (RCPSP) flavour. Concretely, given the number of workers and the goal of production, we wish to complete production with a pre-specified amount of storage space such that any component listed below occupies one space once produced; the space is freed when it is fed into another production task as raw material. We further assume the goal of production (i.e., cars) does not occupy any spaces upon completion.
Pamuretas has the following charming characteristics:
Pamuretas assumes a customized input of number of maximum threads that may run concurrently. It leverages the abundant working resource if and when possible but contemplate discreetly when facing limited resource to guarantee a stable performance.
Pamuretas is shipped with a dedicated scheduler and two dispatchers, through whose delegation and feedback, Pamuretas is able to perform decently well no matter what task it is facing. Under most scenarios, the dynamic task scheduling results a nearly optimal solution.
Pamuretas has two built-in systems for deadlock prevention and handling/recovery; its built-in signaling mechanism enables the feedback between dispatchers such that both competition and hungers between threads are minimized.
Pamuretas adapts the master-slave paradigm, and models the sets of individual tasks as two FIFO queues, where they are enqueued in topological order of the DAG.
The core of Pamuretas lies on its ability of delegating between the key components, i.e., one scheduler and two dispatchers. The main working flow is outlined above. As we shall see in the sequel, these are vital to Pamuretas' performance and robustness.
Important Note for MacOS Users: the dependency
deprecated in the
clang distribution. Please do NOT run it, otherwise
unexpected error may occur.
Pamuretas is written in pure
First, clone this repo via
$ git clone https://github.com/zjiayao/Pamuretas
Then we may build from the source:
$ cd pamuretas && make
By default, we turn off the
debug mode, which makes Pamuretas
less verbose while working, to turn it on, add the following
$ make debug=on
This would build an executable
Invoking from CLI
Pamuretas takes three parameters:
$ ./pamuretas [goals] [spaces] [workers]
where all of them should be positive integers. Pamuretas does not allow input configurations which are insolvable:
$ ./pamuretas 1 8 1 [Fatal] Single worker requires at least 13 space but only 8 given, abort
We also provide a handful of utilities for easy-benchmarking. These
are included in the
python plotter, a
c test-case enumerator and several
scripts for prettifying the result. Please refer to the comments therein
Adversarial Examples (Defended)
Here we attach a series of screencasts exhibiting the robustness of Pamuretas under critical scenarios.
Single Worker, Thirteen Space
This is a very critical scenario, a slight misgiving would trap a less-carefully implemented algorithm.
1 worker produces 1 car given critical storage spaces in ~40.02 seconds.
Single Space, Huge Working Force
This posts two difficulties: how to optimally use the only one space; and how to avoid workers from competiting with each other.
100 workers produce 2 cars given only one storage spaces in ~38.20 seconds.
Pamuretas has been thoroughly tested against over five thousand configurations. This indeed yields some interesting benchmarking results.
We first find out the time needed for one production goal with sufficient resource:
which is about 15 seconds.
Single/Multiple Production Goals
|Surface of Production Time against Worker-Space|
We note Pamuretas is able to utilize the abundant working force and storage space rather quickly; it also does not suffer from deadlock and alike when very limited spaces are provided. The results are nearly-optimal compared to the baseline computed from last section.
When we scale up the production task, we note the contours are nearly identical -- with one peak appearing at low space region. This suggested limited space posts more threats to Pamuretas.
Furthermore, at abundant resource region, the running time of Pamuretas is near optimal and remains stable (the plateau near the reader).
Optimal Performance Analysis
We proceed to consider the throughput and scalability of Pamuretas.
|Maximum Throughput (cars/sec)||Production Time with Unlimited Resource|
First noted the plotter automatically extrapolates the values at the boundary, hence resulting the slope near reader. This should be ignored though. The increasing along the diagonal of worker-space plane implies a good scalability. Under the scenario where sufficient resources are available, Pamuretas is able to finish the production near the optimal time, i.e., around 15 seconds.
Limitation and Future Work
Currently, the Worker Pool is implemented as a vannila array. This may become the bottleneck of the scalability, if we have tens of or thousands of workers, say. This may be solved by implementing a tree structure for fast indexing.
Acknowledgment and Disclaimer
Part of this project has been submitted in partial fulfillment for the course Operating Systems offered by HKU, 2017-18. We thank the teaching staff for providing this motivating problem.