Solved-Projects that teaches how to construct an operating system -solved

Table 2 – Round robin scheduler

The Process Structure and the Code Files

As you learned in the lectures, a process contains the program code and its current activity (context). Normally, a program code is a binary file, which contains the instructions that are executable by the CPU. However, for the sake of simplicity, we will use text files (*.code) that represent the executable code of the processes in this project. The structure of the text file is shown in Table 3. Each row of the text file represents an instruction in which the first column presents the name of this instruction and the second column is the execution time required by the CPU to complete this instruction.

INSTRUCTION NAME	INSTRUCTION EXECUTION TIME (ms)
instruction_1	20
instruction_2	50
instruction_3	50
instruction_4	20
instruction_5	30
.	.
.	.
.	.
Exit	10

Table 3 – A Text Based Program Code File Example

Each of the rows is an atomic operation, which means if the CPU starts to execute this instruction, it cannot be interrupted to schedule another process until the execution of that instruction is completed. Assume that the “time slot” is 100 ms in BUnix and we start executing the process with the program code in Table 3. The scheduler should stop the process after “instruction_3” (execution time 120ms), add this process to the end of ready queue, and start executing the first process in the queue. Finally, you might have noticed that the last instruction name is “exit” which means that this process should be finalized and it should be removed from the system after the exit instruction is executed.

In addition to the program code, we need to store the current activity (context) of a process to reschedule this process and continue to execute it with the CPU. Normally, the current activity of a process contains different elements such as the registers in the CPU and stack of the process. In BUnix, we just need to store the line number of the last executed instruction before sending this process to the ready queue.

Don’t get confused by the names of the instructions. These are not real machine codes and YOU WILL NOT REALLY EXECUTE. The only important thing is that you have to calculate the execution times of these instructions correctly. So, you can stop a process, send it back to the ready queue, and run another process at the right time.

The Process Definition File

The process definition file (definition.ini) is a text file that provides the initial information of the processes in the system. The following table shows the structure of this file.

Table 4 – The Process Definition File Structure

Each row represents a process in the system. You should have noticed that process names are unique, but more than one process may be assigned to the same program code.

The Scheduler Code

This component is a C code that parses the process definition file and schedules these processes using the round robin algorithm. The design should have at least the following parts:

• The parsing of the “process definition file” and the programming code files.

• The process data structure, which includes at least the programming code address (or the filename) and the last executed line information.

• A FIFO queue to implement the ready queue.

• A round robin scheduler that maintains the queue.

• An output mechanism that generates a file to show the ready queue whenever it is changed by the algorithm. The output file should have the format that is shown in Table 5.

[TIME]::HEAD-[Ready Queue]-TAIL

100::HEAD—TAIL

200::HEAD-P1-P2-TAIL

340::HEAD-P2-P3-P1-TAIL

450::HEAD-P3-P1-P2-TAIL

590::HEAD-P1-P2-P4-P3-TAIL

630::HEAD-P2-P4-P3-TAIL

790::HEAD-P4-P3-P2-TAIL

930::HEAD-P3-P2-P4-TAIL

970::HEAD-P2-P4-TAIL

1090::HEAD-P4-P2-TAIL

1130::HEAD-P2-TAIL

1230::HEAD-P2-TAIL

1240::HEAD—TAIL

Table 5 – The Output File Format