Hello, if you have any need, please feel free to consult us, this is my wechat: wx91due

Part III - Design and Implementation of an API Simulator: fork/exec [5 marks]

The objective of this assignment is to build a small API simulator.

We will reuse Assignment 1, where we simulated an interrupt system.

The system has one CPU. The OS use fixed partitions in memory. The simulator uses the following data structures:

i. Memory Partitions: fixed partitions

You have a simulated space of 100 Mb of user space available, divided in six fixed partitions:

1- 40 Mb

2- 25 Mb

3- 15 Mb

4- 10 Mb

5- 8 Mb

6- 2 Mb

You need to define a table (array of structs, linked list) with the following structure:

Partition Number	Size	Code
Unsigned int	Unsigned int	String. Only use free, init or the program name (this will be clear as you read through the assignment)

ii. PCB:

Using the textbook/slides, you need to define a table (array of structs, linked list) with similar contents of those found in a PCB (only include the information needed: PID, CPU, and I/O information, remaining CPU time – needed to represent preemption –, partition number where the process is located). You should add any other information that your simulator needs.

Your simulator will initialize the PCB table and pid 0, called init, which will use Partition 6; it uses 1 Mb of memory.

iii. List of External Files

This is another table (implemented as an array of structs, linked list, or your choice of data structure for the table). Its initial contents are loaded from an external text file (external_files.txt) at the start of the simulation. It simulates your persistent memory (hard drive, USB, flash drive…). It only contains a list of programs as follows:

Program Name	Size of the program when loaded in memory
String; 20 chars	Unsigned Integer

The simulator will implement simulated versions of the fork, exec system calls. For all the system calls, the simulation should try to reproduce the behavior of this state diagram (from Silberschatz et al.) which was implemented in Assignment 1, for both system calls and interrupts.

In this simulator, we implement the two system calls as follows:

a. fork ()

a. Simulates SYSCALL (Assignment 1)

b. The ISR copies the PCB of the parent to the child process

c. At the end of the ISR, you call the routine scheduler (), which is, for now, empty (it just displays “scheduler called”).

d. Return from the ISR (Assignment 1)

b. exec (file_name)

a. Simulates SYSCALL (Assignment 1)

b. The ISR uses the size of the new executable; should search the file in the file list, and obtain the memory size

c. It finds an empty partition where the executable fits (Assume best-fit policy)

d. It marks the partition as occupied

e. It records which process is using that partition

f. It updates the PCB with the new information

g. At the end of the ISR, you call the routine scheduler (), which is, for now, empty (it just displays “scheduler called”).

h. Return from the ISR (Assignment 1)

All the activities by fork and exec must be logged by the simulator. Each step is associated with a random execution time between 1 and 10 milliseconds.

The simulator checks the Ready Queue (in the PCB table you defined), grabs the first process available, and simulates its execution. How? By reading the program name from the external_files table and loading the appropriate program into the simulator. Other than that, you execute the fork, exec and exit syscall as above.

Assumptions to be made:

When the EXEC system call is invoked, assume it is only called by the child process and not by the parent.
The child process has a higher priority than the parent process. Therefore, the child process should be executed until completion before resuming the parent process. This means that the simulator does not account for orphaned processes yet; the child must finish execution before the parent process can terminate.
EXEC is found at vector 3 and for FORK is found at vector 2

At the end of each simulated system call, the simulator saves, in a file called system_status.txt the following information:

. Current simulated time

. PCB table

Mandatory Test Scenarios

1. Only Init is in the system. Init runs this code:

FORK, 10

EXEC program1, 50

FORK, 15

EXEC program2, 25

Contents of program1:

CPU, 100

Contents of program2:

SYSCALL 4, 125

2. Only Init is in the system. Init runs this code:

FORK, 17

EXEC program1, 16

Contents of program1:

FORK, 15

EXEC program2, 33

Contents of program2:

CPU, 53

SYCALL 5, 128

END_IO 11, 115

3. Only Init is in the system. Init runs this code:

FORK, 20

EXEC program1, 60

Program 1 runs this code:

FORK, 17

EXEC program2, 46

Program 2 runs this code

FORK, 16

EXEC program3, 58

Program 3 runs this code:

CPU, 50

SYSCALL 6, 110

CPU, 15

END_IO 10, 220

Your Test Scenarios

After these three tests, you should create at least 2 other tests to be submitted.

The input to your program:

List of external files in external_files.txt
Initial trace file in trace.txt
Your vector table in vector_table.txt
This is not an input, but you need the traces of your external programs accessible by your simulator. The simulator will look at the respective program name from the EXEC call, check memory requirements from the external_files table and fetch the corresponding program.

Test cases and an example document will be posted on Brightspace, as in Assignment 1.

文章

Part III - Design and Implementation of an API Simulator: fork/exec [5 marks]

Hello, if you have any need, please feel free to consult us, this is my wechat: wx91due

发表评论