Developing a Platform Using Petri Nets and GPenSIM for Simulation of Multiprocessor Scheduling Algorithms

Abstract

Efficient multiprocessor scheduling is pivotal in optimizing the performance of parallel computing systems. This paper leverages the power of Petri nets and the tool GPenSIM to model and simulate a variety of multiprocessor scheduling algorithms (the basic algorithms such as first come first serve, shortest job first, and round robin, and more sophisticated schedulers like multi-level feedback queue and Linux’s completely fair scheduler). This paper presents the evaluation of three crucial performance metrics in multiprocessor scheduling (such as turnaround time, response time, and throughput) under various scheduling algorithms. However, the primary focus of the paper is to develop a robust simulation platform consisting of Petri Modules to facilitate the dynamic representation of concurrent processes, enabling us to explore the real-time interactions and dependencies in a multiprocessor environment; more advanced and newer schedulers can be tested with the simulation platform presented in this paper.

1. Introduction

This paper seeks to explore and evaluate diverse scheduling algorithms in a multiprocessor setting using Petri nets. The simulation will be facilitated by the General-purpose Petri Net Simulator (GPenSIM) [1], a toolbox that runs on the MATLAB platform.

Given the ongoing decline in Moore’s law, CPU manufacturers have responded by increasing core counts to sustain performance improvements [2]. With this rise in core count, effective scheduling in operating systems has become crucial. Unlike in the past, where tasks were scheduled on a single core, modern operating systems must now manage multiple cores, in which the scheduler plays a pivotal role in maximizing CPU performance.

The primary goal of the project behind this paper is to develop a simulation platform with Petri nets and GPenSIM so that past, present, and future (new) scheduling algorithms can be tested and evaluated. The simulation platform consists of Petri modules (modular Petri nets).

This paper assesses five distinct scheduling algorithms in a multiprocessor environment using this simulation platform based on Petri modules. This paper evaluates fundamental schedulers such as first come first serve (FCFS), shortest job first (SJF), and round robin (RR). Additionally, this paper analyzes more sophisticated schedulers like multi-level feedback queue (MLFQ) and Linux’s completely fair scheduler (CFS) [3]. Through a comprehensive comparison across diverse workloads, our objective is to assess the performance of these schedulers, focusing on key metrics like turnaround time and response time. Given its implementation in the Linux kernel, the CFS serves as a valuable benchmark for comparing against less complex scheduling algorithms such as FCFS, SJF, and RR.

The structure of this paper: Section 2 presents a compact literature study on multiprocessor scheduling. Section 3 provides a comprehensive background and theoretical foundation for the concepts and methodologies used in this paper. Section 4 introduces Petri nets and the GPenSIM tool. Section 5 outlines the design and architecture of our Petri net-based simulation platform, clarifying the key components and their roles in modeling multiprocessor scheduling algorithms. In Section 6, we test the platform we developed. We present an in-depth analysis of the simulation results, highlighting the performance characteristics of various scheduling algorithms and their impact on turnaround time, response time, and throughput. Finally, in Section 7, based on the extensive testing, we highlight the limitations of our simulations and the simulation platform. Also, we propose some further work.

2. Literature Review on Multiprocessor Scheduling

There are numerous works on multiprocessor scheduling. For a thorough study, the following books are recommended: [4,5,6].

Some works on multiprocessor scheduling focus on benchmarking newer scheduling algorithms or comparing the performance of different algorithms. Refs. [7,8] test new genetic algorithm-based schedulers in a multiprocessor environment. Ref. [9] uses a hybrid particle swarm optimization algorithm as a scheduler. Ref. [10] uses a network flow algorithm and [11] explores a bin-packing algorithm.

The literature study also reveals works that explore optimization of multiprocessor scheduling by changing or introducing newer policies. Ref. [12] explores the effect of adding deadline constraints to tasks; a similar technique (‘deadline tardiness bounds’) is explored in [13]. Ref. [14] considers the fixed-priority policy with utilization bounds to make the scheduling more fairer for the competing processes. Ref. [15] studies the effect of pre-ordering (‘partially ordered’) tasks for optimal scheduling. Finally, ref. [16] considers a feature concerning jobs that may be rejected with penalties, and how the penalties improve the overall metrics.

The third group of works focus on hardware. Ref. [17] studies the application of dynamic voltage scaling (DVS) to reduce the dynamic power consumption of embedded multiprocessors. Ref. [18] studies the application of processor-cache affinity information in a shared-memory multiprocessor system. Finally, ref. [19] considers multiprocessor scheduling in systems that are characterized by delays (delays are prevalent).

Novelty of our paper: though this paper presents the evaluation of three crucial performance metrics in multiprocessor scheduling (such as turnaround time, response time, and throughput) under various scheduling algorithms, the primary focus of this paper is to develop a robust simulation platform consisting of Petri modules. By developing this platform, we hope to facilitate the dynamic representation of concurrent processes, enabling us to explore the real-time interactions and dependencies in a multiprocessor environment so that more advanced and newer schedulers can be tested.

3. Background

This section introduces the concept of processes, a well-known abstraction used in operating systems. Additionally, this section explores various scheduling algorithms that will be implemented and tested in later sections. Finally, this section examines how a scheduling algorithm designed for a single CPU can be adapted for multiprocessor scheduling.

3.1. Process

Operating systems like Windows and Linux utilize an abstraction known as process to execute programs [3]. This abstraction creates the illusion that each process has its own dedicated CPU, even though it shares a single or multiple CPUs with other processes. Typically, a process can exist in one of three different states:

• Running: this state indicates that the process is actively running on a CPU.
• Ready: here, the process is prepared to run but has not been selected by the scheduler yet.
• Blocked/waiting: in this state, a process has usually undergone some form of I/O operation and is currently blocked or waiting.

Processes can comprise one or multiple threads. For simplicity, this paper only considers processes with a single thread.

Typically, the operating system schedules processes and threads with unknown running time; hence, some assumptions are made for simulations. We will assume that the runtime for each incoming process is known, enabling us to simulate the same load on different scheduling algorithms. The word job is used in the book but will be used interchangeably with process and thread for the rest of this paper. Each job will retain essential information for simulation purposes, enabling the generation of metrics upon completion of the simulation. The produced jobs will encompass the following:

• PID: a unique identifier for the job.
• Arrival time: the moment the job was generated.
• Started time: the initial scheduling time of the job.
• Finish time: the completion time of the job.
• Remaining time: the duration remaining for the job.
• Total time: the overall time required for job execution.
• Scheduled: the number of times the job has been scheduled (due to context switching).
• Migrated: the count of times the job has been migrated.

For some specific scheduling algorithms, extra fields are necessary.

3.2. First Come First Serve

The first come first serve (FCFS) scheduling algorithm is one of the simplest and most straightforward process scheduling algorithms used in computer operating systems. Our FCFS description is based on the description in book [3]. In this algorithm, processes are scheduled based on the order of their arrival in the queue. The process that arrives first is given precedence and is scheduled first, followed by subsequent arrivals in the same sequential order. FCFS brings with it a set of advantages. Firstly, its simplicity is highly commendable, making it easy to implement and comprehend, thus rendering it an ideal choice for beginners and simple scheduling scenarios. Moreover, FCFS inherently upholds fairness by ensuring that processes are served in the order they arrive, preventing starvation for any particular process. Additionally, the absence of the need to consider priorities further simplifies the scheduling process. However, FCFS is not without its limitations. It may result in a higher average waiting time than other scheduling algorithms, especially if long-running processes arrive first. Furthermore, FCFS may not be the most efficient in utilizing the CPU’s processing power, mainly if shorter processes arrive later in the queue. An additional drawback is the potential occurrence of the convoy effect within the FCFS algorithm, where smaller processes are delayed due to processes with long running times being scheduled first. This will result in one slower process, causing the entire group of processes to perform slowly, wasting CPU time and other resources.

3.3. Shortest Job First

The shortest job first (SJF) scheduling algorithm is a non-preemptive process scheduling approach where processes are scheduled based on the duration of their CPU burst times [3]. SJF selects the process with the shortest CPU burst time for execution first. This strategy minimizes the average waiting time, resulting in efficient CPU utilization and improved system performance. However, SJF requires accurate prediction or estimation of CPU burst times, which can be challenging, particularly for new or unknown processes. Moreover, longer processes may experience starvation if a continuous influx of shorter processes persists. In interactive systems, where users expect quick responses, SJF may not be ideal due to the unpredictable nature of user inputs. SJF remains a crucial scheduling policy despite these considerations because it can optimize resource utilization and enhance system efficiency.

3.4. Round Robin

The round robin scheduling algorithm is a widely used preemptive process scheduling technique in computer operating systems [3]. In this approach, each process is assigned a fixed time slice, known as a time quantum, during which it can execute on the CPU. Once a process exhausts its time quantum, it is moved to the back of the ready queue, allowing the following process in line to receive CPU time. Round robin aims to provide fair and equal CPU time to each process, preventing any single process from monopolizing the CPU. However, this algorithm can introduce an overhead due to the frequent context switches associated with moving between processes. The time quantum must be carefully chosen to balance achieving responsiveness and minimizing context switch overhead. Round robin scheduling is valued for its simplicity, effectiveness in time-sharing systems, and prevention of process starvation, ensuring a relatively even distribution of CPU time among processes. One drawback with RR is that it is impossible to prioritize interactive jobs such as mouse and keyboard input, even though it has a good response time compared with FCFS.

3.5. Multi-Level Feedback Queue

The multi-level feedback queue (MLFQ) scheduling algorithm explanation is based on the description in book [3]. MLFQ is a dynamic priority-based process scheduling technique employed in some operating systems. MLFQ dynamically assigns processes to various priority queues based on their recent behavior, aiming to optimize response time and turnaround time. This algorithm initiates processes in the highest-priority queue and transitions to lower-priority queues based on CPU usage patterns. MLFQ will learn about the processes and use their past behavior to predict future patterns. Based on this, the priority of the processes will be changed. The algorithm ensures fairness by continually adjusting process priorities in response to their behavior. However, significant drawbacks are identified. One major concern is the potential for interactive jobs to monopolize CPU time, leaving long-running jobs starved for processing resources. Additionally, the algorithm is susceptible to manipulation, allowing clever users to trick the scheduler and gain an unfair CPU share through strategic use of I/O operations. Another limitation is the algorithm’s inability to adapt to program behavior changes over time, overlooking transitions from CPU-bound to interactive phases. MLFQ settings are carefully adjusted to overcome these obstacles, such as queue quantity, time slice sizes, and priority boosting frequency.

MLFQ adheres to the rules outlined in the bullet points below [3]. Some rules have been adapted to enhance compatibility within a Petri net model.

• Rule 1: select the job with the highest priority.
• Rule 2: in the event of two jobs sharing the same highest priority, execute them round robin.
• Rule 3: assign the highest priority to jobs entering the queue.
• Rule 4: if the allocated time for a job elapses, decrease the job’s priority by one.
• Rule 5: if jobs have been in the queue for a specified period without running, elevate their priority to the highest.

3.6. Completely Fair Scheduler

The completely fair scheduler (CFS) description is based on the description from book [3]. The Linux OS initially employed an exceptionally sophisticated MLFQ known as O(1) scheduler. However, Linus Torvalds deemed it overly complex and challenging to reason about. In Linux version 2.6.23 in 2007, the CFS, invented by Ingo Molnar [20], became the default scheduler. Unlike traditional schedulers that rely on fixed time slices, CFS prioritizes fairness by aiming to distribute the CPU’s processing power among competing processes evenly. It achieves this through a dynamic counting-based approach known as virtual runtime (vruntime), where each process accumulates vruntime in proportion to its actual running time. To ensure a fair distribution of CPU resources during scheduling decisions, CFS chooses the process with the lowest vruntime to run next.

CFS employs a parameter known as sched_latency to determine a process’s duration before undergoing a context switch. The default setting for sched_latency is commonly configured at 48 ms, resulting in a corresponding time_slice of 48 ms. The actual time_slice is additionally influenced by the presence of other processes in the queue. When there are n processes, the time_slice is calculated as

$$time\_slice=\frac{sched\_latency}{n}$$

(1)

Here, time_slice represents the time a process runs before it is switched out. However, as the number of processes increases, sched_latency may become extremely small, potentially leading to the overhead of context switching outweighing the allocated time. To address this issue, CFS introduces a parameter called min_granularity, which establishes the minimum time slice a process will run before switching out. The default value for min_granularity in Linux is 6 ms. So, the time slice is calculated using Equation (2).

$$time\_slice=max\left(\frac{sched\_latency}{n},min\_graunularity\right)$$

(2)

CFS prioritizes fair CPU scheduling and allows for fine-grained control over process priority using a mechanism known as niceness, which assigns a nice value to each process in the system. The nice parameter can be modified to allocate a higher CPU share to specific processes. This parameter ranges from $-20$ to $+19$ for a process, with the default value being 0. A positive nice value assigns a lower priority to a process, whereas a negative value confers a higher priority. The concept of niceness provides a practical means for users or administrators to exert influence over the allocated CPU share for specific processes. CFS associates the nice values of processes with specific weights, as illustrated in

Table 1. Mapping of niceness to weight in the form $niceness\mapsto weight$.

$-20\mapsto 88761$	$-19\mapsto 71755$	$-18\mapsto 56483$	$-17\mapsto 46273$	$-16\mapsto 36291$
$-15\mapsto 29154$	$-14\mapsto 23254$	$-13\mapsto 18705$	$-12\mapsto 14949$	$-11\mapsto 11916$
$-10\mapsto 9548$	$-9\mapsto 7620$	$-8\mapsto 6100$	$-7\mapsto 4904$	$-6\mapsto 3906$
$-5\mapsto 3121$	$-4\mapsto 2501$	$-3\mapsto 1991$	$-2\mapsto 1586$	$-1\mapsto 1277$
$0\mapsto 1024$	$1\mapsto 820$	$2\mapsto 655$	$3\mapsto 526$	$4\mapsto 423$
$5\mapsto 335$	$6\mapsto 272$	$7\mapsto 215$	$8\mapsto 172$	$9\mapsto 137$
$10\mapsto 110$	$11\mapsto 87$	$12\mapsto 70$	$13\mapsto 56$	$14\mapsto 45$
$15\mapsto 36$	$16\mapsto 29$	$17\mapsto 23$	$18\mapsto 18$	$19\mapsto 15$

.

By applying the weight of a given process, k, and dividing it by the combined weight of all the processes, n, we end up with Equation (3), the designated running time for job k.

$$time\_slic{e}_k=max\left(\frac{weigh{t}_k}{{\sum }_{i=0}^{n-1}weigh{t}_i}·sched\_latency,min\_granularity\right)$$

(3)

CFS relies on a periodic timer interrupt to assess the frequency and decide if a context switch is required. Due to potential decimal points in time_slice_k, specific processes might run slightly longer than intended. However, this effect should balance out over time, providing an approximate utilization of CPU time. In our simulation, we simplify this by rounding the value.

Additionally, CFS adjusts its vruntime calculation based on the weight, ensuring fair distribution of CPU resources while considering niceness and process priorities. This intelligent adaptation maintains proportional CPU allocation, preserving fairness even when niceness values differ. For instance, a process with a higher niceness value will accrue vruntime at an increased rate compared with one with a lower niceness value. The accumulation of vruntime is depicted in Equation (4), where $runtim{e}_i$ represents the actual CPU time utilized by process i, $weigh{t}_0=1024$ is the default weight for niceness 0 as indicated in Table 1, and $weigh{t}_i$ corresponds to the weight of process i.

$$vruntim{e}_i=vruntim{e}_i+\frac{weigh{t}_0}{weigh{t}_i}·runtim{e}_i$$

(4)

3.6.1. Red-Black Trees

Finding the next job to be scheduled is a crucial aspect of any scheduler, particularly for CFS, which is the scheduler used in the globally widespread Linux operating system. The basic solution involves maintaining everything in a queue-like data structure and looping through it whenever the next job needs to be scheduled. However, this simple solution has a time complexity of $O\left(n\right)$, scaling linearly with the number of jobs in the queue, which can range from 100 to 1000 in modern systems. CFS tackles this issue using a data structure known as a red-black tree. This balanced tree is a priority queue, enabling insertion and deletion in $O(logn)$ time complexity. This approach scales much more efficiently than using a fundamental data structure like an array. It is important to note that the complex red–black tree data structure will not be implemented in the simulation.

3.6.2. New Jobs and Sleeping Jobs

When new jobs enter the system or transition from a blocked state to the ready state, issues may arise with their vruntime lagging behind active jobs. If a new job with vruntime set to zero encounters a minimum vruntime of, say, 500 among existing jobs, the new job could monopolize the CPU until its vruntime catches up. A similar situation may occur when a job transitions from a prolonged blocked/waiting state.

To address the issue of CPU monopolization, jobs entering the system and blocked jobs transitioning to the ready state should receive a new vruntime. This new vruntime is set to the minimum vruntime of all currently running jobs. By doing so, we prevent the newly arrived or unblocked jobs from monopolizing the CPU and ensure fair scheduling among all active jobs.

3.7. Multiprocessor Scheduling

While the preceding subsections detailed various scheduling algorithms in single-core systems, the primary emphasis of this paper is a simulation directed toward scheduling in a multiprocessor environment. By utilizing a single CPU, scheduling is employed to create the illusion that each process in the system has its own CPU. In reality, all processes share a single CPU, and the concepts of context switching and sophisticated scheduling algorithms attempt to conceal this fact. In a multi-CPU system, parallelism is achievable, as two processes can run simultaneously on different cores. In theory, it might sound like a system with four CPUs will exhibit throughput that is four times greater than a system with a single CPU. However, in practice, this is not the case. This occurs because each CPU has its own caches and translation lookaside buffer (TLB), which is only accessible from its associated CPU. CPUs utilize caches and TLB for enhanced performance by leveraging the principle of locality. This principle states that a CPU will frequently access the same set of memory locations for a specific period, focusing on memory addresses close to each other, such as loops in a program. When a process runs on CPU1 and is switched to CPU2, the cache and TLB must be updated. Moving a process from one CPU to another, known as migration, requires updating the cache and TLB. While the simulation will not specifically focus on cache and TLB issues, it will monitor the frequency of process migrations to provide insights into how often such migrations might occur [3]. Figure 1 depicts a typical multiprocessor architecture, where each CPU has its own cache but the memory is shared.

There are two usual approaches for multiprocessor scheduling, both of which are explained below.

• Single-queue: when transitioning from a single CPU scheduler to a multi-CPU scheduler, the most basic approach involves sharing a single queue that all processes arrive at. All CPUs use the same scheduling algorithm and fetch jobs accordingly from the queue. While this approach is simple to understand and easy to implement, it has significant drawbacks. The main issue is the need for some form of locking to prevent two CPUs from running the same process. Introducing locking can significantly reduce performance, especially with many CPUs, as each CPU must acquire the lock, find the correct process, and release the lock. This additional overhead is an undesirable property. Another issue with the single-queue approach is cache affinity, as processes might run on a different CPU each time they are scheduled. Figure 2 illustrates how the execution might look using a single-queue setup with four CPUs.
• Multi-queue: an approach that minimizes contention for acquiring locks is using a queue for each CPU in the system. If the number of CPUs is n, there will be n queues. When a job arrives in the system, it is typically placed in the queue with the least number of jobs. Each CPU can schedule the jobs in its local queue without worrying about sharing and synchronization. This approach also helps with cache affinity, as jobs do not jump between different CPUs but stay consistent on the same one. However, this approach has drawbacks, particularly in terms of load balancing. For example, if two CPUs have three jobs in total, where CPU one has one job in its queue while CPU two has two jobs in its queue, then the job in CPU one will run more than the two jobs in the queue for CPU two. Another drawback of the multi-queue approach is the need for redistribution if one CPU is idle while the others have multiple jobs in their queues. Figure 3 illustrates how the execution might look with a multi-queue setup with two CPUs.

4. Petri Nets and GPenSIM

This paper uses Petri nets to model the AGVs. More specifically, modular Petri nets.

4.1. Petri Nets

A Petri net is composed of two elements: places and transitions. A transition represents an event or an action performed by an object; the event can be anything from mixing smoothies, combining two elements, disassembling, and charging. A place represents a state or position in a system. For example, if a machine is available or how far a car has traveled on the road. An arc connects places and transitions; since Petri nets is a bipartite graph, an arc cannot connect the same type of elements (e.g., a place to another place). A token represents an object that goes from one place to another through the firing of a transition.

Petri Nets: Definition

Petri net (P/T Petri net) is a four-tuple [21,22]:

$$PTPN=(P,T,F,M_0),$$

where,

• P: set of places, $P=\{p_1,p_2,\dots ,p_{n_p}\}.$
• T: set of transitions, $T=\{t_1,t_2,\dots ,t_{n_t}\}$.
  P ∩ T = ∅.
• F: set of directed arcs; $F\subseteq (P\times T)\cup (T\times P).$ The default arc weight, W, of $f_{ij}$ ($f_{ij}\in F$, an arc going from $p_i$ to $t_j$ or from $t_i$ to $p_j)$ is singleton, unless stated otherwise.
• M: row vector of markings (tokens) on the set of places.
  $M=[M\left(p_1\right),M\left(p_2\right),\dots ,M\left(p_{n_p}\right)]\in N^{n_p}$,    $M_0$ is the initial marking.

4.2. Modular Petri Nets

A modular Petri net is a Petri net that consists of one or more Petri modules and zero or more inter-modular connectors (IMCs). A Petri module is like any other Petri net, but with some specific rules:

• Tokens can only enter a Petri module through its input ports, which are transitions.
• Tokens can only exit a Petri module through its output ports, which are also transitions.
• Local places and transitions of a Petri module cannot have any direct arcs with elements outside the Petri module.

Modular Petri nets possess two important benefits over the non-modular Petri nets [23]: modular Petri nets allow independent development and testing of Petri modules. After thorough testing of individual Petri modules, they are connected by IMCs to form the overall model. Petri modules can run on different computers. Hence, they run faster (take less simulation time).

Modular Petri Nets: Definition

Modular Petri net (MPN) = Petri nodules + IMCs (inter-modular connectors)

An MPN consists of one more Petri module and zero or more IMCs.

Formal definition of MPN:

An MPN is defined as a two-tuple:

$$MPN=(\mathbb{M},\mathcal{C})$$

• $\mathbb{M}={\sum }_{i=0}^m{\mathsf{\Phi }}_i$ (one or more Petri modules).
• $\mathcal{C}={\sum }_{j=0}^n{\mathsf{\Psi }}_j$ (zero or more IMCs).

Formal definition of Petri module:

A Petri module is defined as a six-tuple:

$$\mathsf{\Phi }=(P_{L\mathsf{\Phi }},T_{IP\mathsf{\Phi }},T_{L\mathsf{\Phi }},T_{OP\mathsf{\Phi }},A_{\mathsf{\Phi }},M_{\mathsf{\Phi }0}),$$

where,

• $T_{IP\mathsf{\Phi }}\subseteq T$: $T_{IP\mathsf{\Phi }}$ (input ports).
• $T_{L\mathsf{\Phi }}\subseteq T$: $T_{L\mathsf{\Phi }}$ (local transitions).
• $T_{OP\mathsf{\Phi }}\subseteq T$: $T_{OP\mathsf{\Phi }}$ (output ports).
• $T_{IP\mathsf{\Phi }}$, $T_{L\mathsf{\Phi }}$, and $T_{OP\mathsf{\Phi }}$, all are mutually exclusive:
  $T_{IP\mathsf{\Phi }}\cap T_{L\mathsf{\Phi }}=T_{L\mathsf{\Phi }}\cap T_{OP\mathsf{\Phi }}=T_{OP\mathsf{\Phi }}\cap T_{IP\mathsf{\Phi }}=\varnothing$.
• $T_{\mathsf{\Phi }}=T_{IP\mathsf{\Phi }}\cup T_{L\mathsf{\Phi }}\cup T_{OP\mathsf{\Phi }}$ (the transitions of the module).
• $P_{L\mathsf{\Phi }}\subseteq P$ the local places. Since a module has only local places, $P_{\mathsf{\Phi }}\equiv P_{L\mathsf{\Phi }}$.
• $\forall p\in P_{L\mathsf{\Phi }}$,

  -

  $•p\in (T_{\mathsf{\Phi }}\cup \varnothing )$ (a local place can be input by transition inside the module or none).

  -

  $p•\in (T_{\mathsf{\Phi }}\cup \varnothing )$ (an output of a local place can be transition inside the module or none).

• $\forall t\in T_{L\mathsf{\Phi }}$,

  -

  $•t\in (P_{L\mathsf{\Phi }}\cup \varnothing )$ (input place of a module transition is a local place or none).

  -

  $t•\in (P_{L\mathsf{\Phi }}\cup \varnothing )$ (output place of a module transition is a local place or none).

• $\forall t\in T_{IP\mathsf{\Phi }}$

  -

  $•t\in (P_{L\mathsf{\Phi }}\cup P_{IM}\cup \varnothing )$ (input places of input ports can be local places, places in IMCs, or none).

  -

  $t•\in (P_{L\mathsf{\Phi }}\cup \varnothing )$ (output places of output ports can be local places, places in IMCs, or none).

• $\forall t\in T_{OP\mathsf{\Phi }}$

  -

  $•t\in (P_{L\mathsf{\Phi }}\cup \varnothing )$ (input places of output ports can be local places or an empty set).

  -

  $t•\in (P_{L\mathsf{\Phi }}\cup P_{IM}\cup \varnothing )$ (output places of output ports can be local places, IM-places, or none).

• $A_{\mathsf{\Phi }}\subseteq (P_L\times T_{\mathsf{\Phi }})\cup (T_{\mathsf{\Phi }}\times P_L)$: where $a_{ij}\in A_{\mathsf{\Phi }}$ (internal arcs).
• $M_{\mathsf{\Phi }0}=\left[M\left(p_L\right)\right]$ (initial markings in local places).

Formal definition of inter-modular connector:

An inter-modular connector (IMC) is defined as a four-tuple:

$$\mathsf{\Psi }=(P_{\mathsf{\Psi }},T_{\mathsf{\Psi }},A_{\mathsf{\Psi }},M_{\mathsf{\Psi }0})$$

where,

• $P_{\mathsf{\Psi }}\subseteq P$: $P_{\mathsf{\Psi }}$ is the set of places in the IMC (known as the IM-places). $\forall p\in P_{\mathsf{\Psi }}$,

  -

  $•p\in (T_{OP}\cup T_{\mathsf{\Psi }}\cup \varnothing )$ (input transitions of IM-places can be output ports of modules, IM-transitions of this specific IMC, or none).

  -

  $p•\in (T_{IP}\cup T_{\mathsf{\Psi }}\cup \varnothing )$ (output transitions of IM-places can be input ports of modules, IM-transitions of this specific IMC, or none).

  (IM-places are not allowed to have direct connections with local transitions of modules.)

• $\forall p\in P_{\mathsf{\Psi }},\forall ip\notin P_{{\mathsf{\Phi }}_i}$ (a local place of a module cannot be an IM-place).
• $T_{\mathsf{\Psi }}\subseteq T$: $T_{\mathsf{\Psi }}$ is the transitions of the IMC (aka IM-transitions). $\forall t\in T_{\mathsf{\Phi }}$,

  -

  $•t\in (P_{\mathsf{\Psi }}\cup \varnothing )$ (input places of IM-transitions can be IM-places of this specific IMC or none).

  -

  $t•\in (P_{\mathsf{\Psi }}\cup \varnothing )$ (output places of IM-transitions can be IM-places of this specific IMC or none).

• $\forall t\in T_{\mathsf{\Psi }},\forall it\notin T_{{\mathsf{\Phi }}_i}$ (an IM-transition is not allowed to be a member of any module).
• $A_{\mathsf{\Psi }}\subseteq (P_{\mathsf{\Psi }}\times (T_{\mathsf{\Psi }}\cup T_{IP}))\cup ((T_{\mathsf{\Psi }}\cup T_{OP})\times P_{\mathsf{\Psi }})$: where $a_{ij}\in A_{\mathsf{\Psi }}$ is the IMC arc.
• $M_{\mathsf{\Psi }0}=\left[M\left(p_{\mathsf{\Psi }}\right)\right]$ initial markings in IM-places.

4.3. GPenSIM

This paper uses GPenSIM for the implementation and simulation of the Petri net model. GPenSIM allows model logic to be imposed on transitions via the pre-processor and post-processor files [24]. Also, GPenSIM supports the use of resources, providing a compact Petri net model for systems with a large number of resources. A resource represents something that is needed for a machine to work; for example, a robot arm can be a resource.

GPenSIM is a MATLAB toolbox developed by the third author of this paper [24]; GPenSIM is freely available [1]. GPenSIM’s coloring facility is useful for developing Petri net models of real-life discrete systems [25]. Also, GPenSIM allows modeling large discrete systems with modular Petri nets [23].

5. Method and Design

This section discusses the overall architectural design, the modular approach, and using design patterns and architectural templates to organize the system.

5.1. Overall Design

When simulating various scheduling algorithms in a multiprocessor environment, a simplified system suffices compared with a comprehensive operating system like Windows or Linux. We have omitted features such as memory management, I/O operations, and program execution details from our model. The exclusion of these elements was a deliberate choice driven by their complexity. We focus solely on the minimal essential information needed to compute metrics and appropriately schedule jobs for their designated duration. The methods outlined below are essential for facilitating the simulation of various schedulers.

• Job generation: a transition within the Petri net will generate jobs using specific values outlined in Section 3.1. The characteristics of the jobs will also depend on the scheduling algorithm employed. Jobs may be generated through random, static, or external dataset-based methods. Subsequently, all generated jobs will be placed in a global queue accessible to all CPUs.
• Queues: freshly generated jobs are deposited into the global queue, following the previously outlined procedure. Each CPU is equipped with its dedicated local queue. For a system comprising n CPUs, there will be n local queues, resulting in a total of $n+1$ queues, including the global queue. Jobs are transferred from the global queue to the local queue with the least number of jobs. In scenarios where multiple local queues possess an equal minimum number of jobs, the decision regarding which local queue will receive the job will be left to GPenSIM. As a result, the quantity of jobs in each local queue remains relatively consistent.
• Redistribute jobs: in the presence of an idle CPU, it should be able to migrate a job from one local queue to another. Job migration is contingent upon the global and local queues’ lack of jobs. Under these conditions, a job from another local queue will return to the global queue and undergo fair redistribution.
• Scheduling: CPUs select executable jobs from their respective local queues to run within a specified time frame. The scheduling algorithm remains consistent across all CPUs, focusing on the jobs within its local queue. The selection of a particular job is contingent upon the implemented scheduler. Certain scheduling algorithms may require additional fields in the jobs to facilitate the proper selection of the next job.
• Time: each job encompasses several fields necessary for metric calculations, as detailed in Section 3.1, contingent on having access to time. GPenSIM employs a clock called the global timer, a discrete value incremented by $1/4$ of the shortest firing transition [24]. The global timer in GPenSIM will be used when assigning time to jobs. The rationale behind this choice will be explained later as we delve into the advantages and disadvantages of utilizing this built-in global timer.

5.2. Modular Approach

Multiprocessor scheduling is a complex topic, and creating a comprehensive Petri module that functions seamlessly is no straightforward task. Our chosen strategy involves an incremental approach. We commence with a basic model featuring a solitary CPU employing the most straightforward scheduling algorithm, FCFS. Once the single CPU module demonstrates accurate functionality, we progress to model more intricate scheduling algorithms in a sequential order: SJF → RR → MLFQ → CFS. Following the successful implementation of these scheduling algorithms, our attention shifts to multiprocessor scheduling. The final phase involves a focus on the redistribution aspect.

5.2.1. Single CPU

The initial approach involves modeling a single CPU with minimal requirements, equivalent to an FCFS scheduler. The objective was to create a model with two modules—one for the local queue and another for the CPU—and assign all the scheduling responsibilities to a single transition in the local queue module. This ensures that the overall model flow remains consistent, regardless of the implemented scheduling algorithm. The initial model, depicted in Figure 4, comprises two modules: Local Queue and CPU. Additionally, it includes inter-modular connectors (IMC) that integrate the various modules, enabling the simulation.

When using Petri modules, there are four distinct elements [23]:

• Input ports: these are the transitions where tokens can arrive in the module from an IMC, such as tCpuQueue in the local queue module in Figure 4.
• Output ports: these are the transitions where tokens can go from a module to a place in an IMC, like tInitJob in the local queue module in Figure 4.
• Local transitions: these are only accessible from inside the module as they are not input or output ports.
• Local places: these are only accessible from inside the module as they cannot receive tokens from an outside transition, and an external transition cannot take tokens from them.

The input and output ports in Figure 4 are transitions that overlap between a module and IMC.

System flow: the model shown in Figure 4 is described in the bullet points below.

• The first transition in the model, tJobGenerator, is responsible for placing tokens inside the place pGlobalQueue, with a color corresponding to its job ID. All the jobs that arrive in pGlobalQueue wait to be placed in the place pLQ. Although the place pGlobalQueue is not necessary for a single CPU, it is a component of the soon-to-come multiprocessor model.
• The local queue pLQ is where the scheduling algorithm chooses the next job to be scheduled. The transition tStealLQ is deactivated in the single CPU model but is used in the multiprocessor model to redistribute jobs. The MLFQ scheduler includes an additional transition, tBoostLQ, which boosts jobs that have been in the local queue for an extended period without being scheduled.
• Transition tInitJob is where the scheduling algorithm runs to decide the next job to be scheduled. Additionally, there is a place pResource that is consumed by tInitJob, ensuring that only a single job can run at any given time. Without this place, having multiple jobs in the job loop would have been possible. This place enables mutual exclusion of pJobLoop.
• Upon the job’s arrival at the pJobLoop location, it will execute for a specified time slice determined by the implemented scheduling algorithm. If the time slice is non-zero, the tDecrement transition will execute the job for 1 time unit and decrease the time slice by 1 time unit. When the time slice reaches zero, the tTimeSliceOver transition will execute.
• If the job is not completed, it returns to the pLQ place and awaits rescheduling. Upon job completion, the tTimeSliceOver transition assigns a color “Done” to the token. Transition tJobDone verifies if any tokens in pJobBuffer bear the color “Done” signifying job completion and enabling placement into pCompleted location.
• Once a job is requeued or completed, the acquired resource in pResource is returned, facilitating the scheduling of a new job.

Updated model: the model detailed above employs a single token in place pResource to emulate a shared resource, preventing multiple jobs from running simultaneously. GPenSIM features a built-in resource mechanism explicitly designed for such scenarios. Rather than delegating resource allocation to the Petri net, a higher abstraction within GPenSIM assumes this responsibility. Figure 5 depicts the same model as the previous section but utilizing GPenSIM’s built-in resources. The tInitJob transition requests access to the CPU and is only permitted to execute if the CPU resource is available; otherwise, it waits and retries later. The tRequeueInput and tJobDone transitions release the CPU resource, enabling the scheduling of another job on the CPU. Everything else in Figure 5 follows the same flow as the previous model.

Regardless of the implemented scheduling algorithm, the overall model remains the same. Each algorithm utilizes the same modules, as depicted in Figure 5. The scheduling logic is embedded in pre-processor and post-processor files. The transition accountable for the scheduling decision is tInitJob, orchestrating job scheduling based on the implemented algorithm. Specific scheduling algorithms require additional parameters for decision-making, which are either included in the main simulation file, attached to the jobs, or both.

5.2.2. Multiprocessor

The model depicted in Figure 5 is designed for a single CPU and functions effectively in that context. To simulate scheduling algorithms in a multiprocessor environment, the original model must be replicated to include as many instances as there are CPUs in the system. For example, if there are four CPUs, there should be four models, each with its own local queue module and CPU module. Figure 6 illustrates the model configuration with four CPUs. Duplicating the pGlobalQueue and tJobGenerator components is unnecessary, as these should be shared among the CPUs for job distribution.

The overall flow of the multiprocessor model remains consistent with the single CPU model, with two transitions requiring modification: tCpuQueue and tStealLQ. In a single CPU environment, tCpuQueue can always fire, and tStealLQ may not need to fire at all. However, these transitions are crucial for distributing and redistributing jobs in a multiprocessor environment. The transition tCpuQueue for a CPU should only fire if its local queue has the fewest jobs. This ensures a fair distribution of jobs, minimizing idle times for the system. In scenarios where job running times vary, one CPU can accumulate multiple jobs while another remains jobless. In such a scenario, the tStealLQ transition should take a job from pLQ and return it to pGlobalQueue, enabling redistribution to an idle CPU.

5.3. Implementation

This subsection will go over the programming environment and show how the different scheduling algorithms are implemented based on the information from Section 3.

The simulation is written in MATLAB, utilizing the General-purpose Petri Net Simulator (GPenSIM) platform [1]. Each scheduling algorithm is implemented separately but shares a substantial amount of common code to streamline the development process. This section goes through the implementation of job generation, how we update job data under the simulation, and how each CPU requests and releases the built-in resources of GPenSIM.

Due to brevity and due to the technical nature of the simulation code, the implementation of the model (coding) is not presented in this paper. The complete code is available for any interested readers, along with a more detailed (technical) report and a user guide.

6. Testing, Analysis, and Results

The datasets used in the simulations consist of two distinct sets:

• The short job dataset: this dataset consists of jobs with relatively short execution times. These jobs are designed to simulate processes that are completed quickly.
• Mixed job dataset: in contrast, the “mixed job dataset” provides a more complex and realistic test environment. It simulates scenarios where the CPU must manage a mix of short- and long-running jobs, closely resembling real-world situations where processes with varying execution times are constantly competing for system resources. This dataset helps us assess how well our scheduling algorithms adapt to the challenges presented by a diverse set of jobs.

A function generates short jobs using a normal distribution, $N(\mu ,\sigma )$, with $\mu$ as the mean and $\sigma$ as the standard deviation. For calculating the total time of a short job, we set $\mu =25$ and $\sigma =10$, with values capped at $[1,50]$. Long jobs are generated using different $\mu$ and $\sigma$ values, specifically $\mu =100$, $\sigma =25$, and capped at $[50,150]$. Each dataset comprises 250 jobs, with the short dataset exclusively containing short jobs. The mixed dataset consists of an equal mix of $50\%$ short and $50\%$ long jobs. In the mixed datasets, short jobs are represented by odd job IDs, while even job IDs correspond to long jobs. Figure 7 provides a visualization of the job execution time distribution for both datasets.

The niceness parameter for each job is generated using a normal distribution with $N(0,6)$ and capped at $[-20,19]$. Since most jobs are expected to have a niceness of 0, the normal distribution with $\mu =0$ is well-suited. A standard deviation of $\sigma =6$ is used to introduce variability among jobs, assigning higher priority to some jobs and lower priority to others.

The final step in dataset generation involves setting the arrival times of jobs. To introduce realism, we uniformly assigned arrival times in the range $[1,\left({\sum }_{i=1}^n{T}_{(i,total)}\right)/6]$, except for the first 10 jobs, which have an arrival time of 0. These initial jobs serve as a startup phase. Dividing the total running time by 6 accommodates the presence of four CPUs, effectively reducing the overall time by approximately 4. We increased it by 2 to ensure jobs arrive closer to each other. The jobs are sorted based on arrival time, meaning that, for a job with ID i, its arrival time satisfies $i-1\le i\le i+1$.

We employ two datasets to simulate diverse workloads, comprehensively assessing how scheduling algorithms perform under various conditions. This approach allows us to discern whether a scheduler excels primarily with short jobs or adapts well to a mixed load comprising both interactive and resource-intensive tasks.

6.1. Analysis

The metrics we will utilize to analyze the scheduling algorithm are outlined in the bullet points below.

• Turnaround time: the turnaround time of a process is determined by subtracting the arrival time of the process in the system from the time at which the process is completed [3].

  $$T_{turnaround}=T_{completion}-T_{arrival}$$

  (5)
• Response time: the response time of a process is determined by subtracting the arrival time of the process in the system from the time at which the process is first scheduled [3].

  $$T_{response}=T_{firstrun}-T_{arrival}$$

  (6)
• Throughput: traditionally, throughput in the realm of scheduling algorithms is defined as the number of processes completed within a specified time frame. In this analysis, we opt to examine throughput on a per-process basis, calculated by taking the minimum time a process should run and dividing it by the turnaround time. This yields a value within the $(0,1]$ range, where higher values indicate superior throughput for the respective process.

  $$P_{throughput}=\frac{T_{total}}{T_{turnaround}}$$

  (7)
• Queue loads: at predetermined intervals, the system measures the size of all queues. The queue sizes will illustrate the fluctuations over time throughout the simulation, providing a detailed view of load balancing.
• Jain’s fairness index: Jain’s fairness index is employed to evaluate how fairly CPU time is distributed among different processes. It provides a quantitative measure of fairness in terms of resource allocation in a multiprocess environment. It can be used to assess the effectiveness of scheduling algorithms in ensuring equitable access to resources for various processes [26]. Equation (8) is used for measuring the fairness, where n is the number of processes and $x_i$ represents the individual share of the resource allocated to entity i (throughput for process i). The value ranges between 0 and 1, where a higher value corresponds to increased fairness.

  $$f\left(x\right)=\frac{{\left({\sum }_{i=1}^n{x}_i\right)}^2}{n·{\sum }_{i=1}^n{x}_i^2}$$

  (8)

Given that many of the metrics outlined above are on a per-process basis, calculating averages is also feasible. For instance, to determine the average turnaround time, we sum the turnaround times of all processes and divide by the total number of processes in the system. This principle also applies to response time and throughput.

6.2. Result

This section evaluates various scheduling algorithms using the metrics outlined earlier. We begin by examining the average metrics for each algorithm in both short and mixed datasets. To provide a comprehensive view of performance, we present box plots illustrating median, standard deviations, and outliers. Following this, we delve into specific metrics, covering both datasets’ turnaround time, response time, and throughput. Lastly, we assess CPU load balancing.

Average Performance

Table 2. Metrics evaluating the performance of both short and mixed jobs.

	FCFS		SJF		RR		MLFQ		CFS
	Short	Mixed	Short	Mixed	Short	Mixed	Short	Mixed	Short	Mixed
Turnaround	$329.77$	$855.26$	$238.58$	$502.78$	$610.26$	$1323.56$	$714.87$	$1324.76$	$579.86$	$1260.69$
Response	$303.30$	$794.27$	$212.10$	$441.79$	$115.10$	$112.659$	$6.766$	$7.37$	$21.281$	$13.76$
Throughput	$0.122$	$0.106$	$0.365$	$0.338$	$0.059$	$0.053$	$0.064$	$0.068$	$0.142$	$0.098$
Jain’s FI	$0.423$	$0.358$	$0.690$	$0.681$	$0.414$	$0.685$	$0.278$	$0.443$	$0.302$	$0.341$
Migrations	0	0	0	0	23	29	4	29	12	14
Scheduled	250	250	250	250	1189	2619	997	2056	970	2167

presents a comprehensive evaluation of various scheduling algorithms, utilizing the metrics previously defined in this study. Taking into account both short and mixed datasets, we first analyze the average performance metrics for each scheduling algorithm. The turnaround time, response time, and throughput are all computed as averages, while Jain’s fairness index is calculated using Equation (8). The migrations field represents the total number of migrations that occurred during the simulation, while scheduled is the total count of context switches.

Turnaround time: the average turnaround time is notably lower in FCFS and SJF compared with the other scheduling algorithms. This result was anticipated since FCFS and SJF executed each job to completion without any form of context switching. In the box plots depicted in Figure 8 and Figure 9, SJF exhibits significant outliers in turnaround time, attributed to its practice of prioritizing short jobs while delaying the execution of long ones. In contrast, RR, MLFQ, and CFS show a much closer alignment in average turnaround time, as they allocate a time slice to each job for execution. The elevated standard deviation observed for CFS in the box plots can be attributed to the niceness level, which assigns higher priority to specific jobs. On the contrary, except for MLFQ, other scheduling algorithms assign an equal priority to every job. It is worth highlighting that SJF can be proven optimal when all jobs arrive simultaneously [3]. Therefore, SJF serves as a valuable benchmark when comparing other scheduling algorithms in terms of turnaround time.

Response time: the average response time for MLFQ and CFS surpasses that of the other scheduling algorithms, particularly FCFS and SJF. While one might anticipate RR to exhibit a better response time due to its consistent context switching at a given time quantum, the queuing mechanism, and prioritizing jobs in a first-in-first-out order, which results in later arrivals being placed at the back of the queue and experiencing delays. MLFQ and CFS, employing a form of priority, often allow newly arrived jobs to run at an earlier stage, contributing to an overall improvement in the system’s response time. Both SJF and CFS exhibit more outliers in their response times, as evident in the box plots of Figure 8 and Figure 9.

Throughput: since throughput is calculated as the turnaround divided by the total time for a given job, schedulers with high throughput are desirable. However, it is crucial to note that the throughput, especially for SJF, can be somewhat skewed due to certain jobs experiencing prolonged periods of starvation. The box plots provide a useful indication of how various scheduling algorithms perform concerning throughput. Moreover, it is worth acknowledging that values close to 1 may indicate the first arrived job in the local queue, especially for FCFS, SJF, and CFS.

Jain’s fairness index: with the exception of SJF and RR with mixed jobs, the fairness values for most scheduling algorithms are closely aligned. This suggests a relatively even distribution of CPUs. What was somewhat unexpected, however, was that CFS had the lowest fairness value. In hindsight, this observation aligns with expectations, given that the niceness level significantly influences the standard deviation of the turnaround, as previously discussed. Consequently, this impact extends to the throughput, a factor that Jain’s fairness index considers.

Migrations and scheduled: in the case of FCFS and SJF, there are zero recorded migrations, even though jobs might have transitioned from one CPU to another. The calculation of migrations is based on job execution on a CPU; if a job does not execute on two different CPUs, it is not considered as migrated. While fewer migrations are generally preferable, schedulers allocating time slices to jobs, such as RR, MLFQ, and CFS, are expected to encounter migrations. It is important to note that the migration count does not account for scenarios where a job runs on multiple CPUs sequentially, which can significantly impact performance more than a single migration.

The scheduled metrics reflect the count of context switches during the simulation, happening when a job is either completed or preempted to schedule a new job. As the number of context switches rises, the simulation time extends due to the necessity of transitions with a firing time of $0.1$ for each switch. This effect will become more apparent in the upcoming graphs. Consequently, a discernible pattern emerges, demonstrating a higher turnaround time with an increase in context switches, as one would reasonably expect.

In the Appendix A, Appendix B, Appendix C and Appendix D, we explore turnaround time, response time, and throughput in more detail.

7. Discussion

In Section 6, we put the developed platform to test; after examining the results (Section 6.2), we can conclude that CFS and MLFQ stand out as superior scheduling algorithms. They perform well overall and do not rely on prior knowledge of job running times, which is unrealistic and a drawback for SJF. While fair, the RR scheduler has inherent issues, especially when dealing with a high number of simultaneous jobs in the queue. This leads to low throughput and, in some cases, poor response time.

Given that CFS is employed in the Linux kernel, our simulations provide insights into its efficacy, showcasing good turnaround time and exceptionally low response time. Additionally, it supports the assignment of priority to jobs, allowing for prioritization of interactive tasks.

However, the MLFQ scheduler faces challenges, such as determining the optimal number of queues and their runtime. The crucial boosting mechanism also poses difficulty in adjustment. Despite these challenges, both CFS and MLFQ offer valuable insights into different scenarios, contributing to a comprehensive understanding of their strengths and limitations.

7.1. Limitations of This Work

Our work on developing the simulation platform is not complete, as the simulation results show that there is still room for improvement. There are also some other weaknesses and limitations. In this section, we identify some of them.

I/O operations: the implemented model involves certain simplifications compared with real-world scheduling, such as all jobs being in either the running or ready state. In reality, some processes are blocked/waiting due to ongoing I/O operations. This model may not accurately simulate scenarios where certain scheduling algorithms perform better on interactive workloads, as it does not account for processes in the blocked state.

No cache: hardware employs various types of caches to enhance performance [27]. These typically include:

• Instruction cache: speeds up instruction fetching.
• Data cache: stores and retrieves data more rapidly, often organized in L1, L2, and L3 cache layers.
• Translation lookaside buffer: facilitates the swift mapping of virtual addresses to physical addresses, assisting memory management.

The model/simulation does not incorporate any of these cache types, rendering the test results somewhat unrealistic in comparison with a real operating system. The most significant impact on system performance arises from job migrations, where all accumulated caches in a given CPU are squandered upon process migration. Since the migration process is infrequent, its impact on the results is minimal.

Scheduling overhead: the simulation aims to capture the overhead of frequent context switching but may deviate significantly from reality. Our approach introduces a context-switching overhead of around 5–20% depending on running time, whereas real operating systems might exhibit $1\%$. Furthermore, the model overlooks other complexities present in operating systems, such as memory usage variations and diverse CPU loads. The system in our simulation always aims to run at $100\%$, which might not align with the realistic scenarios encountered in many use cases.

Datasets: it is important to note that the data used in the simulation are randomly generated and do not represent any real-world workload. Although multiple datasets were employed for comparison, using real-world workloads from high-traffic servers could have provided a more accurate assessment of the scheduling algorithms compared with randomly generated datasets.

Job stealing algorithm: the job stealing process presents inherent challenges when combined with the distribution aspect. In various scenarios, a job transitioning from a local queue may find itself back in the same local queue or end up in another local queue where the CPU is already occupied. The redistribution mechanism aims to place the job in the local queue of an idle CPU, but this guarantee is not ensured in our case when multiple local queues have the minimum amount of jobs. It might not happen in certain instances, as the job could circulate among busy CPUs without reaching an idle one. Given sufficient time, the job is expected to reach an idle CPU eventually.

The job stealing algorithm takes only a single job from a local queue and places it into the global queue for further distribution. In specific scenarios, a local queue t may have multiple jobs (e.g., 10) while another local queue q is at 0. The algorithm will steal only one job at a time, suggesting that the migrated job will receive more CPU time compared with the jobs remaining in the local queue t.

7.2. Further Work

As the final section of this paper, we suggest some pointers for further work.

Increase/decrease CPU count: adjusting the simulation to increase or decrease its scale is a time-consuming process involving the copying and customization of all necessary files for each CPU, each configured to match its respective CPU index. This approach is prone to bugs, as it becomes challenging to identify instances where, for example, CPU3 might inadvertently utilize queue data intended for CPU2. An intriguing extension would involve the use of generics or a parser that allows the creation of the Petri net through a graphical user interface. This enhancement could simplify the scaling process for varying counts, providing a more user-friendly experience.

Include I/O operations: including I/O operations in the simulation would provide valuable insights into the performance of scheduling algorithms. One approach to simulate the blocked state of a process due to I/O operations is to integrate I/O operations into the job generation process. Additionally, introducing an extra transition that handles tokens at specific times can help capture the realistic dynamics of the blocked state.

Improve the job stealing algorithm: addressing the identified issues in the redistribution algorithm, as discussed in the previous subsection, would be a valuable avenue for exploration. Enhancements in this area could further improve the fairness of schedulers and mitigate potential overheads in the existing implementation. Exploring options such as utilizing global variables or introducing additional colors to indicate the CPU responsible for taking a job are both viable approaches. However, introducing an extra color would require subsequent removal in a future transition.

More sophisticated adjustments are required to address issues where migrated jobs may unfairly dominate CPU resources. This could involve implementing a dynamic calculation of CPU local queues and redistributing jobs when a queue falls below a certain threshold. Such refinements would contribute to a more balanced allocation of resources and enhance the overall performance of the scheduling algorithms.