Operating System Simulation Lab ( 5CS10)

INTRODUCTION CHAPTER 1

1.1 Operating Sytem :

A computer system can be divided roughly into four components: the hardware, the operating system, the applications programs, and the users (Figure 1). The hardware - the central process-ing unit (CPU), the memory, and the input/output (1/0) devices - provides the basic computing resources. The applications programs - such as compilers, database systems, games, and business programs - define the ways in which these resources are used to solve the computing problems of the users. There may be many different users (people, machines, other computers) trying to solve different problems. Accordingly, there may be many different applications programs. The operat-ing system controls and coordinates the use of the hardware among the various applications pro-grams for the various users.

Fig1: Abstract View of the Components of a Computer System.

Operating System manages: Process Management Memory Management File Management Scheduling of process Networking Protection of Data

1.2 Process Scheduling

The objective of multiprogramming is to have some process running at all times,to maximize CPU utilization. The objective of time sharing is to switch the CPU among processes so fre-quently that users can interact with each program while it is running. For a uniprocessor system, there will never be more than one running process. If there are more processes, the rest will have to wait until the CPU is free and can be rescheduled.

1.2.1 Preemptive Scheduling

CPU scheduling decisions may take place under the following four circumstances:

1. When a process switches from the running state to the waiting state (for example, I/O request, or invocation of wait for the termination of one of the child processes)2. When a process switches from the running state to the ready state (for example, when an inter-rupt occurs)3. When a process switches from the waiting state to the ready state (for example, completion of I/O)4. When a process terminatesFor circumstances 1 and 4, there is no choice in terms of scheduling. A new process (if one exists in the ready queue) must be selected for execution. There is a choice, however, for circumstances 2 and 3. When scheduling takes place only under circumstances 1 and 4, we say the scheduling scheme is nonpreemptive; otherwise, the scheduling scheme is preemptive. Under nonpreemp-tive scheduling, once the CPU has been allocated to a process, the process keeps the CPU until it releases the CPU either by terminating or by switching to the waiting state. This scheduling method is used by the Microsoft Windows environment. It is the only method that can be used on certain hardware platforms, because it does not require the special hardware (for example, a timer) needed for preemptive scheduling.

1.2.2 Scheduling Criteria

Different CPU scheduling algorithms have different properties and may favor one class of pro-cesses over another. In choosing which algorithm to use in a particular situation, we must con-sider the properties of the various algorithms. Many criteria have been suggested for comparing CPU scheduling algorithms. Which characteristics are used for comparison can make a substan-tial difference in the determination of the best algorithm. Criteria that are used include the fol-lowing:

CPU utilization. We want to keep the CPU as busy as possible. CPU utilization may range from 0 to 100 percent. In a real system, it should range from 40 percent (for a lightly loaded system) to 90 percent (for a heavily used system).

Throughput. If the CPU is busy executing processes, then work is being done. One mea-sure of work is the number of processes that are completed per time unit, called through-put. For long processes, this rate may be one per second.

Turnaround time. From the point of view of a particular process, the important crite-rion is how long it takes to execute that process. The interval from the time of submission of a process to the time of completion is the turnaround time. Turnaround time is the sum of the periods spent waiting to get into memory, waiting in the ready queue, execut-ing on the CPU, and doing I/O.

Waiting time. The CPU scheduling algorithm does not affect the amount of time during which a process executes or does I/O; it affects only the amount of time that a process spends waiting in the ready queue. Waiting time is the sum of the periods spent waiting in the ready queue.

Response time. In an interactive system, turnaround time may not be the best criterion. Often, a process can produce some output fairly early, and can continue computing new results while previous results are being output to the user. Thus, another measure is the time from the submission of a request until the first response is produced. This measure, called response time, is the amount of time it takes to start responding, but not the time that it takes to output that response. The turnaround time is generally limited by the speed of the output device.

1.3 Scheduling Algorithms

CPU scheduling deals with the problem of deciding which of the processes in the ready queue is to be allocated the CpU. There are many different CPU scheduling algorithms. In this section, we describe several of these algorithms.

1.3.1 First-Come, First-Served Scheduling

By far the simplest CPU scheduling algorithm is the first-come, first-served scheduling (FCFS) algorithm. With this scheme, the process that requests the CPU first is allocated the CPU first. The implementation of the FCFS policy is easily managed with a FIFO queue. When a process enters the ready queue, its PCB is linked onto the tail of the queue. When the CPU is free, it is allocated to the process at the head of the queue. The running process is then removed from the queue.

1.3.2 Shortest-Job-First Scheduling

A different approach to CPU scheduling is the shortest-job-first (SJF) algorithm. This algorithm associates with each process the length of the latter's next CPU burst. When the CPU is available, it is assigned to the process that has the smallest next CPU burst. If two processes have the same length next CPU burst, FCFS scheduling is used to break the tie. Note that a more appropriate term would be the shortest next CPU burst, because the scheduling is done by examining the length of the next CPU-burst of a process, rather than its total length.

1.3.3 Priority Scheduling

The SJF algorithm is a special case of the general priority scheduling algorithm. A priority is as-sociated with each process, and the CPU is allocated to the process with the highest priority. Equal-priority processes are scheduled in FCFS order.

An SJF algorithm is simply a priority algorithm where the priority (p) is the inverse of the (pre-dicted) next CPU burst. The larger the CPU burst, the lower the priority, and vice versa.Note that we discuss scheduling in terms of high priority and low priority. Priorities are gener-ally some fixed range of numbers, such as 0 to 7, or 0 to 4095. However, there is no general agreement on whether 0 is the highest or lowest priority some systems use low numbers to repre-sent low priority; others use low numbers for high priority.

1.3.4 Round-Robin Scheduling

The round-robin (RR) scheduling algorithm is designed especially for timesharing systems. It is similar to FCFS scheduling, but preemption is added to switch between processes. A small unit of time, called a time quantum, or time slice, is defined. A time quantum is generally from 10 to 100 milliseconds. The ready queue is treated as a circular queue. The CPU scheduler goes around the ready queue, allocating the CPU to each process for a time interval of up to 1 time quantum.

To implement RR scheduling, we keep the ready queue as a FIFO queue of processes. New pro-cesses are added to the tail of the ready queue. The CPU scheduler picks the first process from the ready queue, sets a timer to interrupt after 1 time quantum, and dispatches the process.

Implementation of Scheduling Algorithms Chapter 2

Object : Write a program to implement FCFS Scheduling Algorithm in C/C++.

Tool Used: C Language Compiler Windows: Turbo C/ Turbo C++ Linux- GCC/ CC

Program :

#include<stdio.h>main(){

int n,bu[20];float twt,awt,wt[20],tat[20],sum=0;int i;printf("Enter the no of processes:");scanf("%d",&n);for(i=1;i<=n;i++){

printf("\nEnter The BurstTime for Process p[%d]",i);scanf("%d",&bu[i]);

}wt[1]=0;for(i=2;i<=n;i++){

wt[i]=bu[i-1]+wt[i-1];}for(i=1;i<=n;i++){

twt=twt+wt[i];tat[i]=bu[i]+wt[i];sum+=tat[i];

}awt=twt/n;sum=sum/n;printf("\nTotal Waiting Time=%f",twt);printf("\nAverage Waiting Time=%f",awt);printf("\nAverage Turnaround time=%f",sum);

}

Output :

Enter the no of processes:3Enter The BurstTime for Process p[1]2Enter The BurstTime for Process p[2]3Enter The BurstTime for Process p[3]1Total Waiting Time=7.000000Average Waiting Time=2.333333Average Turnaround time=4.333333

Object : Write a program to implement SJF Scheduling Algorithm in C/C++.

Tool Used: C Language Compiler Windows: Turbo C/ Turbo C++ Linux- GCC/ CC

Program :

#include<stdio.h>main(){

int n,bu[20],temp;float twt,awt,wt[20],tat[20],sum=0;int i,j;printf("Enter the no of processes:");scanf("%d",&n);for(i=1;i<=n;i++){

printf("\nEnter The BurstTime for Process p[%d]",i);scanf("%d",&bu[i]);

}for(i=n;i>=1;i--){

for(j=2;j<=n;j++){

if(bu[j-1]>bu[j]){

temp=bu[j-1];bu[j-1]=bu[j];bu[j]=temp;

}}

}wt[1]=0;for(i=2;i<=n;i++){

wt[i]=bu[i-1]+wt[i-1];}for(i=1;i<=n;i++)

{twt=twt+wt[i];tat[i]=bu[i]+wt[i];sum+=tat[i];

}awt=twt/n;sum=sum/n;printf("\nTotal Waiting Time=%f",twt);printf("\nAverage Waiting Time=%f",awt);printf("\nAverage Turnaround time=%f",sum);

}OUTPUT:

Enter the no of processes:3Enter The BurstTime for Process p[1]2Enter The BurstTime for Process p[2]1Enter The BurstTime for Process p[3]3Total Waiting Time=4.000000Average Waiting Time=1.333333Average Turnaround time=3.333333

Object : Write a program to implement Priority Scheduling Algorithm in C/C++.

Tool Used: C Language Compiler Windows: Turbo C/ Turbo C++ Linux- GCC/ CC

Program :

#include<stdio.h>main(){ int n,b[10],w[10],i,j,h,t,tt; int stime[10],a[10],p[10]; float avg=0; printf("\n\tPRIORITY SCHEDULING ALGORITHM"); printf("\n\t*****************************************************\n"); printf("\nEnter howmany jobs:"); scanf("%d",&n); printf("\nEnter burst time & priority for corresponding job....\n"); for(i=1;i<=n;i++) { printf("\nProcess %d:",i); scanf("%d %d",&b[i],&p[i]); a[i]=i; }for(i=1;i<=n;i++)

for(j=i;j<=n;j++) if(p[i]<p[j]) { t=b[i]; tt=a[i]; b[i]=b[j]; a[i]=a[j]; b[j]=t; a[j]=tt; }

w[1]=0; printf("\nprocess %d waiting time is 0",a[1]); for(i=2;i<=n;i++) { w[i]=b[i-1]+w[i-1]; printf("\nProcess %d waiting time: %d",a[i],w[i]);

avg+=w[i]; } printf("\ntotal waiting time:%f",avg); printf("\n\nthe average waiting time is:%f\n",avg/n);

}

OUTPUT:

PRIORITY SCHEDULING ALGORITHM*****************************************************

Enter howmany jobs:2Enter burst time & priority for corresponding job....Process 1:32Process 2:41process 1 waiting time is 0Process 2 waiting time: 3total waiting time:3.000000the average waiting time is:1.500000

Object : Write a program to implement Round Robin Scheduling Algorithm in C/C++.

Tool Used: C Language CompilerWindows: Turbo C/ Turbo C++ Linux- GCC/ CC

Program :

#include<stdio.h>main(){

int n,bu[20],tq,b[20],max=0,Rrobin[20][20],m,j,k,count[10];float twt,awt,wt[20],tat[20],sum=0;int i;printf("Enter the no of processes:");scanf("%d",&n);for(i=1;i<=n;i++){

printf("\nEnter The BurstTime for Process p[%d]",i);scanf("%d",&bu[i]);b[i]=bu[i];if(max<b[i])

max=b[i];wt[i]=0;

}printf("Enter the time quantum:");scanf("%d",&tq);if(max%tq!=0)

//TO find the dimension of the Round robin array

m=max/tq+1;else

m=max/tq;//initializing Round robin arrayfor(i=1;i<=n;i++){

for(j=1;j<=m;j++){

Rrobin[i][j]=0;}

}//placing value in the Rrobin arrayi=1;while(i<=n){

j=1;while(b[i]>0){

if(b[i]>=tq){

b[i]=b[i]-tq;Rrobin[i][j]=tq;j++;

}else{

Rrobin[i][j]=b[i];

b[i]=0;j++;

}}count[i]=j-1;i++;

}

for(j=1;j<=n;j++){

for(i=1;i<=count[j];i++){

if(i==count[j]){

for(k=1;k<j;k++){

if(k!=j)wt[j]+=Rrobin[k][i];

}}else

for(k=1;k<=n;k++){

if(k!=j)wt[j]+=Rrobin[k][i];

}}

}

for(i=1;i<=n;i++)printf("\nWaiting Time for process P[%d]=%f",i,wt[i]);

//calculating Average Weighting Time

for(i=1;i<=n;i++){

twt=twt+wt[i];tat[i]=bu[i]+wt[i];sum+=tat[i];

}awt=twt/n;sum=sum/n;printf("\nTotal Waiting Time=%f",twt);printf("\nAverage Waiting Time=%f",awt);printf("\nAverage Turnaround time=%f",sum);}

OUTPUT:Enter the no of processes:3Enter The BurstTime for Process p[1]2Enter The BurstTime for Process p[2]3Enter The BurstTime for Process p[3]4Enter the time quantum:1Waiting Time for process P[1]=2.000000Waiting Time for process P[2]=4.000000Waiting Time for process P[3]=5.000000Total Waiting Time=11.000000Average Waiting Time=3.666667Average Turnaround time=6.666667

MOSS Simulator Chapter 3

3.1 MOSS Scheduling Simulator

Introduction

The scheduling simulator illustrates the behavior of scheduling algorithms against a simulated mix of process loads. The user can specify the number of processes, the mean and standard devi-ation for compute time and I/O blocking time for each process, and the duration of the simula-tion. At the end of the simulation a statistical summary is presented. Students may also be asked to write their own scheduling algorithms to be used with process loads defined by the instructor.

Running the Simulator

The program reads a configuration file (scheduling.conf) and writes two output files (Summary-Re-sults and Summary-Processes).

To run the program, enter the following command line.

$ java Scheduling scheduling.conf

The program will display "Working..." while the simulation is working, and "Completed." when the simulation is complete.

Working...Completed.

The simulator reads parameters from the configuration file ("scheduling.conf"). It creates a spec-ified number of processes, each of which blocks for input or output after a number of millisec-onds that can be specified for each process. Each process is allowed to run for a randomly gener-ated amount of time, with the amount of time constrained by a specified average (mean) in mil-liseconds, and standard deviations from that average. The simulation may also be bounded in the total length of its run.

After reading the configuration file, the scheduling algorithm then "runs" the processes, causing each to block for input or output after the specified interval until all processes have completed their randomly generated amount of runtime, or until the maximum amount of runtime for the simulation is exceeded.

As the simulation proceeds, a log file ("Summary-Processes") is generated which shows the ac-tivity of the scheduling algorithm as it considers each process in the process queue.

After the simulation halts, a summary report ("Summary-Results") is generated which shows sta-tistics for each process and for the simulation as a whole.

The Configuration File

The configuration file (scheduling.conf) is used to specify various parameters for the simulation, in-cluding:

the number of processes, the mean runtime for a process, the standard deviation in runtime for a process, for each process, how long the process runs before it blocks for input or output, and how long the simulation should run.

Configuration File Options

There are a number of options which can be specified in the configuration file. These are sum-marized in the table below.

Keyword Values Descriptionnumprocess n The number of processes to create for the simulation.meandev n The average length of time in milliseconds that a process should execute

before terminating.standdev n The number of standard deviations from the average length of time a process

should execute before terminating.process n The amount of time in milliseconds that the process should execute before

blocking for input or output. There should be a separate process directive for each process specified by the numprocess directive.

runtime n The maximum amount of time the simulation should run in milliseconds.

Sample Configuration File

The "scheduling.conf" configuration file looks like this:

// # of Processnumprocess 3

// mean deivationmeandev 1100

// standard deviationstanddev 510

// process # I/O blockingprocess 100

process 500process 30

// duration of the simulation in millisecondsruntime 5000

The Summary-Results File

The Summary-Results file contains a summary report describing the simulation and includes one line of summary information for each process. The fields and columns in the report are described in the following table.

Field DescriptionScheduling Type:

The type of the scheduling algorithm used. The value displayed is "hard coded" in the SchedulingAlgorithm.java file.

Scheduling Name:

The name of the scheduling algorithm used. The value displayed is "hard coded" in the SchedulingAlgorithm.java file.

Simulation Run Time:

The number of milliseconds that the simulation ran. This may be less than or equal to the total amount of time specified by the "runtime" configuration parameter.

Mean: The average amount of runtime for the processes as specified by the "meandev" configuration parameter.

Standard Deviation:

The standard deviation from the average amount of runtime for the processes as specified by the "standdev" configuration parameter.

Process # The process number assigned to the process by the simulator. The process number is between 0 and n-1, where n is the number specified by the "numprocess" configuration parameter.

CPU Time The randomly generated total runtime for the process in milliseconds. This is determined by the "meandev" and "standdev" parameters in the configuration file.

IO Blocking The amount of time the process runs before it blocks for input or output. This is specified for each process by a "process" directive in the configuration file.

CPU Completed

The amount of runtime in milliseconds completed for the process. Note that this may be less than the CPU Time for the process if the simulator runs out of time as specified by the "runtime" configuration parameter.

CPU Blocked The number of times the process blocked for input or output during the simulation.

Sample Summary-Results File

The output "Summary-Results" file looks something like this:

Scheduling Type: Batch (Nonpreemptive)Scheduling Name: First-Come First-Served

Simulation Run Time: 2750Mean: 1100Standard Deviation: 510Process #CPU Time IO Blocking CPU Completed CPU Blocked0 1372 (ms) 100 (ms) 1372 (ms) 13 times1 689 (ms) 500 (ms) 689 (ms) 1 times2 689 (ms) 30 (ms) 689 (ms) 22 times

The Summary-Processes File

The Summary-Processes file contains a log of the actions taken by the scheduling algorithm as it considers each process in the scheduling queue.

Each line in the log file is of the following form:

Process: process-number process-status... (cpu-time block-time accumulated-time accumulated-time)

The fields in the line are described in the table below.

Field Descriptionprocess-number

The process number assigned to the process by the simulator. This is a number between 0 and n-1, where n is the value specified for the "numprocess" configuration parameter.

process-status The status of the process at this point in time. If "registered" then the process is under consideration by the scheduling algorithm. If "I/O blocked", then the scheduling algorithm has noticed that the process is blocked for input or output. If "completed", then the scheduling algorithm has noticed that the process has met or exceeded its allocated execution time.

cpu-time The total amount of run time allowed for this process. This number is randomly generated for the process based on the "meandev" and "standdev" values specified in the configuration file.

block-time The amount of time in milliseconds to execute before blocking process. This number is specified for the process by the "process" directive in the configuration file.

accumulated-time

The total amount of time process has executed in milliseconds. (This number appears twice in the log file; one should be removed).

Sample Summary-Processes File

The output "Summary-Processes" file looks something like this:

Process: 0 registered... (1372 100 0 0)Process: 0 I/O blocked... (1372 100 100 100)

Process: 1 registered... (689 500 0 0)Process: 1 I/O blocked... (689 500 500 500)Process: 0 registered... (1372 100 100 100)Process: 0 I/O blocked... (1372 100 200 200)Process: 1 registered... (689 500 500 500)Process: 1 completed... (689 500 689 689)Process: 0 registered... (1372 100 200 200)Process: 0 I/O blocked... (1372 100 300 300)Process: 2 registered... (689 30 0 0)Process: 2 I/O blocked... (689 30 30 30)Process: 0 registered... (1372 100 300 300)Process: 0 I/O blocked... (1372 100 400 400)Process: 2 registered... (689 30 30 30)Process: 2 I/O blocked... (689 30 60 60)Process: 0 registered... (1372 100 400 400)Process: 0 I/O blocked... (1372 100 500 500)Process: 2 registered... (689 30 60 60)Process: 2 I/O blocked... (689 30 90 90)Process: 0 registered... (1372 100 500 500)Process: 0 I/O blocked... (1372 100 600 600)Process: 2 registered... (689 30 90 90)Process: 2 I/O blocked... (689 30 120 120)Process: 0 registered... (1372 100 600 600)Process: 0 I/O blocked... (1372 100 700 700)Process: 2 registered... (689 30 120 120)Process: 2 I/O blocked... (689 30 150 150)Process: 0 registered... (1372 100 700 700)Process: 0 I/O blocked... (1372 100 800 800)Process: 2 registered... (689 30 150 150)Process: 2 I/O blocked... (689 30 180 180)Process: 0 registered... (1372 100 800 800)Process: 0 I/O blocked... (1372 100 900 900)Process: 2 registered... (689 30 180 180)Process: 2 I/O blocked... (689 30 210 210)Process: 0 registered... (1372 100 900 900)Process: 0 I/O blocked... (1372 100 1000 1000)Process: 2 registered... (689 30 210 210)Process: 2 I/O blocked... (689 30 240 240)Process: 0 registered... (1372 100 1000 1000)Process: 0 I/O blocked... (1372 100 1100 1100)Process: 2 registered... (689 30 240 240)Process: 2 I/O blocked... (689 30 270 270)Process: 0 registered... (1372 100 1100 1100)Process: 0 I/O blocked... (1372 100 1200 1200)Process: 2 registered... (689 30 270 270)Process: 2 I/O blocked... (689 30 300 300)

Process: 0 registered... (1372 100 1200 1200)Process: 0 I/O blocked... (1372 100 1300 1300)Process: 2 registered... (689 30 300 300)Process: 2 I/O blocked... (689 30 330 330)Process: 0 registered... (1372 100 1300 1300)Process: 0 completed... (1372 100 1372 1372)Process: 2 registered... (689 30 330 330)Process: 2 I/O blocked... (689 30 360 360)Process: 2 registered... (689 30 360 360)Process: 2 I/O blocked... (689 30 390 390)Process: 2 registered... (689 30 390 390)Process: 2 I/O blocked... (689 30 420 420)Process: 2 registered... (689 30 420 420)Process: 2 I/O blocked... (689 30 450 450)Process: 2 registered... (689 30 450 450)Process: 2 I/O blocked... (689 30 480 480)Process: 2 registered... (689 30 480 480)Process: 2 I/O blocked... (689 30 510 510)Process: 2 registered... (689 30 510 510)Process: 2 I/O blocked... (689 30 540 540)Process: 2 registered... (689 30 540 540)Process: 2 I/O blocked... (689 30 570 570)Process: 2 registered... (689 30 570 570)Process: 2 I/O blocked... (689 30 600 600)Process: 2 registered... (689 30 600 600)Process: 2 I/O blocked... (689 30 630 630)Process: 2 registered... (689 30 630 630)Process: 2 I/O blocked... (689 30 660 660)Process: 2 registered... (689 30 660 660)Process: 2 completed... (689 30 689 689)

Suggested Exercises

1. Create a configuration file in which all processes run an average of 2000 milliseconds with a standard deviation of zero, and which are blocked for input or output every 500 milliseconds. Run the simulation for 10000 milliseconds with 2 processes. Examine the two output files. Try again for 5 processes. Try again for 10 processes. Explain what's happening.

2. Implement a round-robin scheduling algorithm. (Hint: see the Run() method in SchedulingAlgorithm.java).

3.2 MOSS Deadlock Simulator

Introduction

The deadlock simulator illustrates multiple processes competing for one or more resources to in-vestigate the nature and causes of deadlock conditions and how they can be avoided, detected, and resolved. The simulator includes a graphical user interface that allows the student to step through the "programs" being concurrently "executed" by each of the processes and see which processes are blocked by which resources. A typical student lab exercise might require students to write simple "programs" for the simulator to investigate different kinds of resource contention conditions. More advanced students might write a deadlock manager (in Java) based on the tem-plate provided, and test it using "programs" of their own design.

Overview

The deadlock simulator performs the following steps as part of the simulation:

It creates a specified number of simulated processes. For each process, it reads a command file of actions to be performed by that process.

Each action is one of the following: o compute for a specified length of time o request an instance of a specified resource o free an instance of a specified resource o end or halt the process

It creates a specified number of instances for each of several resources. It "executes" the simulation by considering the commands for each process, one at a time,

and either allowing the process to execute, granting it an instance of a requested resource, blocking the process until a requested is available, or ending a process.

As the execution proceeds, the display is updated to reflect the status of each process, and the number of available instances of each resource.

At the end of each cycle of execution, the simulator writes a "log" message indicating the time since the beginning of the simulation, the number of available instances of each re-source, the number of blocked processes, etc.

The user may "step" through the simulation to view the action at each cycle, or may "run" the simulation to completion.

When all processes are halted, the simulation stops.

Running the Simulator

To run the program, enter the following command line.

$ java deadlock a 2 1 >a.logIn this example, a is the prefix for the names of the files containing the commands, (the actual names of the files are "a0.dat", and "a1.dat"), 2 is the number of processes to be created, 1 is the number of instances to create for the first resource, and a.log is the name of the output file.

The program will display a window allowing you to run the simulator. You will notice a row of command buttons across the top, and an informational display below. The left side of the infor-mation display lists the resources and the number of available instances for each, and the right side lists the processes and the current status for each.

The Command Line

The general form of the command line is

$ java deadlock file-name-prefix initial-number-of-processes initial-available-for-resource ...

whereParameter Description

file-name-prefix

Specifies the name prefix for the process command files. The default command file names are generated from this prefix, followed by the number of the process, followed by ".dat" (e.g, "a0.dat", "a1.dat" if "a" is the prefix). The actual names of the files may be entered or modified in the Processes Dialog (see below).

initial-num-ber-of-pro-cesses

Specifies the number of processes to create for the simulation. This should be a non-negative number, usually greater than one. This number may also be entered or modified using the Options Dialog (see below).

initial-avail-able-for-re-source...

Specifies the initial number of instances available for each resource. This should be a sequence of non-negative numbers. For example, "2 1 2 0" indicates that there are four resources, and there are initially two instances of resource 0, one instance of resource 1, two instances of resource 2, and zero instances of re-source 3. The number of resources may also be entered or modified using the Options Dialog (see below). The initial number of instances available for each resource may be entered or modified using the Resources Dialog (see below).

The Control Panel

The main control panel for the simulator includes a row of command buttons, and an informa-tional display.

The buttons:

Buttons DescriptionRun runs the simulation to completion. Note that the simulation pauses and updates the

screen between each step.stop stops the simulation if it is running. This button is only active if the run button has

been pressed.Step runs a single setup of the simulation and updates the display.Options allows you to change various options for the simulator, including the number of re-

sources and the number of processes.Re-sources

allows you to change the configuration for each resource, including the initial and current number of instances available for each resource.

Processes allows you to change the configuration for each process, including current state and the name of the command file for that process.

exit exits the simulation.

The informational display:

Fields DescriptionTime: number of "milliseconds" since the start of the simulation.Resource Available:

A number which identifies the particular resource. Resources are numbered starting with zero.

Process Id A number which identifies the particular process. Processes are numbered starting with zero.

Process state

The current state of the process. This may be U (unknown), C (computable), W (waiting), or H (halted). At the beginning of the simulation, all processes have U status. While a process is computable, it has a C status. If it requests a resource which is unavailable, it enters W status until the resource becomes available. When a process has completed all the commands in its command file or performs a halt command, it enters H status.

Process Resource

The resource for which this process is waiting, if any. This field only has a value if the process is in W status.

The Options Dialog Box

The Options Dialog Box allows you to set general options for the simulator.

The options:

Field DescriptionNumber of Processes

The number of processes to use in the simulation. This should be a non-negative number, usually at least two. Although the program does not enforce a limit, you may not be able to view more than about 10 processes on the informational dis-play on your display screen. The initial value for this option is obtained from the second parameter on the command line, or zero, if not specified. Keep in mind that each process should have a process command file. To set properties for indi-vidual processes, use the Processes Dialog (see below).

Number of Resources

The number of resources available in the simulation. This should be a non-nega-tive number, usually at least one. Although the program does not enforce a limit, you may not be able to view more than about 10 resources on the informational display on your display screen. The initial value for this option is obtained from the number of initial instances for each resource specified on the command line (see above), or zero, if none are specified. This number should be one more than the largest resource number mentioned in any of the process command files for the simulation. To set properties for individual resources, use the Resources Dia-log (see below).

Millisec-onds per step

The number of real-time milliseconds to pause between each cycle of the simula-tor in "run" mode. This is the pause between cycles when you hit the run button. The default value is 1000 milliseconds, or, one second.

The Processes Dialog Box

The Processes Dialog Box allows you to enter or modify properties for each process.

The process properties:Field Description

No. of processs

The number of processes in the simulation. To change this value, use the Options Dialog (see above).

Process id The id number for the process. These numbers are used to identify each process and are assigned by the simulator, starting with zero. These numbers cannot be changed.

Processs File Name

The name of the file from which process commands are read. This may be any valid filename. For convenience, there is a choose button which allows you to browse the file system to choose the file. By default, the name is the prefix string, followed by the process number, followed by ".dat".

The Resources Dialog Box

The Resources Dialog Box allows you to enter and modify properties for each resource.

Field DescriptionNo. of Resources

The number of resources available in the simulation. To change this value, use the Options Dialog (see above).

Resourse Id The id number assigned to the resource. This number is used to identify the resource and is assigned by the simulator and cannot be changed. This is the number which appears in the R (request resource) and F (free resource) commands in the process command files.

Resource Initial

The initial number of available instances of the resource. This number is used when the simulator starts or is reset.

Resource Current

The current number of available instances of the resource. This number may be changed during the simulation to see the effect it may have on processes waiting for the resource.

The Process Command Files

The process command files for the simulator specifies sequence operations to be performed by the process or processes which use the file. There are four operations defined C (compute), R (re-quest resource), F (free resource) and H (halt).

Opera-tions

Description

C msec Compute for the specified number of milliseconds (cycles).R resource-id

Request an instance of the specified resource. If none are available, block the process until the resource becomes available. The resource id should be a non-neg-ative number less than the total number of resources available.

F resource-id

Free an instance of the specified resource. This is usually a resource that was pre-viously requested by the process. The resource id should be a non-negative number less than the total number of resources available.

H Halt the process. This is usually the last operation in the file. Any commands which follow it in the file are ignored. Any file that does not end with this opera-tion is implicitly halted.

Sample Process Command Files

The "a0.dat" input file looks like this:

/*a0.dat

The "a" collection of process data files is meant to simulatetwo processes competing for a single resource. If you runthe simulator with one resource available, one of the processeswill block until the other is done using the resource.*/C 10 // compute for 10 millisecondsR 0 // request resource 0C 10 // compute for 10 millisecondsF 0 // free resource 0H // halt process

Note that the "a1.dat" file is identical. In other words, both files request the same resources at ap-proximately the same time.

The Output File

The output file contains a log of the simulation since the simulation started.

The output file contains one line per cycle executed. The format of each line is:

time = t available = r0 r1 ... rn blocked = nwhere t is the number of milliseconds since the start of the simulation, ri is the number of available instances of each resource, and n is the number of blocked processes.

Sample Output

The output file "a.log" looks something like this: time = 0 available = 1 blocked = 0time = 1 available = 1 blocked = 0time = 2 available = 1 blocked = 0time = 3 available = 1 blocked = 0time = 4 available = 1 blocked = 0time = 5 available = 1 blocked = 0time = 6 available = 1 blocked = 0time = 7 available = 1 blocked = 0time = 8 available = 1 blocked = 0time = 9 available = 1 blocked = 0time = 10 available = 0 blocked = 1time = 11 available = 0 blocked = 1time = 12 available = 0 blocked = 1time = 13 available = 0 blocked = 1time = 14 available = 0 blocked = 1time = 15 available = 0 blocked = 1time = 16 available = 0 blocked = 1time = 17 available = 0 blocked = 1time = 18 available = 0 blocked = 1time = 19 available = 0 blocked = 1time = 20 available = 0 blocked = 0time = 21 available = 0 blocked = 0time = 22 available = 0 blocked = 0time = 23 available = 0 blocked = 0time = 24 available = 0 blocked = 0time = 25 available = 0 blocked = 0time = 26 available = 0 blocked = 0time = 27 available = 0 blocked = 0time = 28 available = 0 blocked = 0time = 29 available = 0 blocked = 0time = 30 available = 1 blocked = 0

In this example, the simulation runs for a total of 30 "milliseconds" and then halts. During the simulation, all processes are computable for 10 milliseconds. During the next 10 milliseconds, the one instance of the resource is allocated to one process, while the other process is blocked. During the final 10 milliseconds, the first process frees the resource, but it is immediately allo-cated by the second process, which then continues to compute, unblocked, to the end of the sim-ulation.

Suggested Exercises

1. Try running the deadlock simulator using the following command: 2. java deadlock a 2 2

Explain why a deadlock does not occur.

3. There are two additional process command files ("b0.dat" and "b1.dat") in the distribu-tion. Run the deadlock simulator with this command:

4. java deadlock b 2 1 1

What happens?

Now try this. java deadlock b 2 1 2

Why does the first command result in a deadlock but the second do not? Explain your answer in terms of what is going on in the process command files, b0.dat and b1.dat.

3.3 MOSS File System Simulator

Introduction

The file system simulator shows the inner workings of a UNIX V7 file system. The simulator reads or creates a file which represents the disk image, and keeps track of allocated and free blocks using a bit map. A typical exercise might be for students to write a program (in Java) which invokes various simulated operating system calls against a well-known disk image pro-vided by the instructor. Students may also be asked to implement indirect blocks, list-based free block managment, or write a utility (like fsck) to check and repair the file system.

Overview

The MOSS File System Simulator is a collection of Java classes which simulate the file system calls available in a typical Unix-like operating system. The "Kernel" class contains methods (functions) like "creat()", "open()", "read()", "write()", "close()", etc., which read and write blocks in an underlying file in much the same way that a real file system would read and write blocks on an underlying disk device.

In addition to the "Kernel" class, there are a number of underlying classes to support the imple-mentation of the kernel. The classes FileSystem, IndexNode, DirectoryEntry, SuperBlock, Block, BitBlock, FileDescriptor, and Stat contain all data structures and algorithms which implement the simulated file system.

Also included are a number of sample programs which can be used to operate on a simulated file system. The Java programs "ls", "cat", "mkdir", "mkfs", etc., perform file system operations to list directories, display files, create directories, and create (initialize) file systems. These pro-

grams illustrate the various file system calls and allow the user to carry out various read and write operations on the simulated file system.

As mentioned above, there is a backing file for our simulated file system. A "dump" program is included with the distribution so that you can examine this file, byte-by-byte. Any dump program may be used (e.g., the "od" program in Unix); we include this one which is simple to use and un-derstand, and can be used with any operating system.

There are a number of ways you can use the simulator to get a better understanding of file sys-tems. You can

use the provided utility programs (mkfs, mkdir, ls, cat, etc.) to perform operations on the simulated file system and use the dump program to examine the underlying file and ob-serve any changes,

examine the sample utility programs to see how they use the system call interface to per-form file operations,

enhance the sample utility programs to provide additional functionality, write your own utility programs to extend the functionality of the simulated file system,

and modify the underlying Kernel and other implementation classes to extend the functional-

ity of the

In the sections which follow, you will learn what you need to know to perform each of these activities.

Using File System Simulator Programs

Using mkfs

The mkfs program creates a file system backing file. It does this by creating a file whose size is specified by the block size and number of blocks given. It writes the superblock, the free list blocks, the inode blocks, and the data blocks for a new file system. Note that it will overwrite any existing file of the name specified, so be careful when you use this program.

This program is similar to the "mkfs" program found in Unix-like operating systems.

The general format for the mkfs command is

java mkfs file-name block-size blockswhere file-name is the name of the backing file to create (e.g., filesys.dat). Note that this is the name of a real file, not a file in simulator. This is the file that the simulator uses to simulate the disk device for the simulated file system. This may be any valid file name in your operating system environment. block-size is the block size to be used for the file system (e.g., 256). This should be a multiple of the index node (i-node) size (usually 64) and the directory entry size (usually 16). Modern operating systems usually use a size of 1024, or 512 bytes. We use 128 or 256 byte block sizes in many of our examples so that you can quickly see what happens when directories grow beyond

one block. This should be a decimal number not less than 64, but less than 32768. blocks is the number of blocks to create in the file system(e.g., 40). This number includes any blocks that may be used for the superblock, free list management, inodes, and data blocks. We use a relatively small number here so that you can quickly see what happens if you run out of disk space. This can be any decimal number greater than 3, but not greater than 2 24 - 1 (the maximum number of blocks), although you may not have sufficient space to create a very large file. For example, the command java mkfs filesys.dat 256 40will create (or overwrite) a file "filesys.dat" so that it contains 40 256-byte blocks for a total of 10240 bytes.

The output from the command should look something like this:

block_size: 256blocks: 40super_blocks: 1free_list_blocks: 1inode_blocks: 8data_blocks: 30block_total: 40

From the output you can see that one block is needed for the superblock, one for free list management, eight for index nodes, and the remaining 30 are available for data blocks.

Why is there 1 block for free list management? Note that 30 blocks require 30 bits in the free list bitmap. Since 256 bytes/block * 8 bits/byte = 2048 bits/block, clearly one bitmap block is suffi-cient to track block allocation for this file system.

Why are there 8 blocks for index nodes? Note that 30 blocks could result in 30 inodes if many one-block files or directories are created. Since each inode requires 64 bytes, only 4 will fit in a block. Therefore, 8 blocks are set aside for up to 32 inodes.

Using mkdir

The mkdir program can be used to create new directories in our simulated file system. It does this by creating the file specified as a directory file, and then writing the directory entries for "." and ".." to the newly created file. Note that all directories leading to the new directory must already exist.

This program is similar to the "mkdir" command in Unix-like and MS-DOS-related operating systems.

The general format for the mkdir command is

java mkdir directory-path

where directory-path is the path of the directory to be created (e.g., "/root", or "temp", or "../home/rayo/moss/filesys"). If directory-path does not begin with a "/", then it is appended to the path name for working directory for the default process. For example, the command java mkdir /homecreates a directory called "home" as a subdirectory of the root directory of the file system.

Similarly, the command

java mkdir /home/rayocreates a directory called "rayo" as a subdirectory of the "home" directory, which is presumed to already exist as a subdirectory of the root directory of the file system.

Using lsThe ls program is used to list information about files and directories in our simulated file system. For each file or directory name given it displays information about the files named, or in the case of directories, for each file in the directories named.

This program is similar to the "ls" command in Unix-like operating systems, or the "dir" com-mand in DOS-related operating systems.

The general format for the ls command is

java ls path-name ...where path-name ...is a space-separated list of one or more file or directory path names.For example, the command java ls /homelists the contents of the "/home" directory. For each file in the directory, a line is printed showing the name of the file or subdirectory, and other pertinent information such as size.

The output from the command should look something like this:

/home:

1 48 . 0 48 .. 2 32 rayototal files: 3

In this case we see that the "/home" directory contains entries for ".", "..", and "rayo".

Using cpThe cp program allows you to copy the contents from one file to another in our simulated file system. If the destination file already exists, it will be overwritten.

This program is similar to the "cp" command in Unix-like operating systems, and the "copy" command in MS-DOS-related operating systems.

The general format of the "cp" command is

java cp input-file-name output-file-namewhere input-file-name is the path-name for the file to be copied (i.e., the source file, andoutput-file-name is the path-name for the file to be created (i.e., the target file.For example, java cp /home/rayo/hello.txt /home/rayo/greeting.txtcreates a new file "/home/rayo/greeting.txt" by copying to it the contents of file "/home/rayo/hello.txt".

Using catThe cat program reads the contents of a named file and writes it to standard output. The cat program is generally used to display the contents of a file.

This program is similar to the "cat" command in Unix-like operating systems, or the "type" com-mand in MS-DOS-related operating systems.

The general format of the cat command line is

java cat file-namewhere file-name is the name of the file from which data are to be read for writing to standard output. For example, java cat /home/rayo/greeting.txtcauses the file "/home/rayo/greeting.txt" to be read, the contents of which are written to standard output.

In this case, the output from the program might look something like this

howdy, podner

3.4 MOSS Memory Management Simulator

Introduction

The memory management simulator illustrates page fault behavior in a paged virtual memory system. The program reads the initial state of the page table and a sequence of virtual memory instructions and writes a trace log indicating the effect of each instruction. It includes a graphical user interface so that students can observe page replacement algorithms at work. Students may be asked to implement a particular page replacement algorithm which the instructor can test by

comparing the output from the student's algorithm to that produced by a working implementa-tion.

Running the Simulator

The program reads a command file, optionally reads a configuration file, displays a GUI window which allows you to execute the command file, and optionally writes a trace file.

To run the program, enter the following command line.

$ java MemoryManagement commands memory.conf

The program will display a window allowing you to run the simulator. You will notice a row of command buttons across the top, two columns of "page" buttons at the left, and an informational display at the right.

Typically you will use the step button to execute a command from the input file, examine infor-mation about any pages by clicking on a page button, and when you're done, quit the simulation using the exit button.

The buttons:

Buttons DescriptionRun runs the simulation to completion. Note that the simulation pauses and updates the screen between each

step.Step runs a single setup of the simulation and updates the display.Reset initializes the simulator and starts from the beginning of the command file.Exit exits the simulation.Page n display information about this virtual page in the display area at the right.

The informational display:

Field Descriptionstatus RUN, STEP, or STOP. This indicates whether the current run or step is completed.Time number of "ns" since the start of the simulation. instruction READ or WRITE. The operation last performed. address the virtual memory address of the operation last performed. Page fault whether the last operation caused a page fault to occur..Virtual page the number of the virtual page being displayed in the fields below. This is the last virtual page ac -

cessed by the simulator, or the last page n button pressed. Physical page the physical page for this virtual page, if any. -1 indicates that no physical page is associated with

this virtual page. R whether this page has been read. (1=yes, 0=no) M whether this page has been modified. (1=yes, 0=no) inMenTime number of ns ago the physical page was allocated to this virtual page. last-TouchTime

number of ns ago the physical page was last modified.

Low low virtual memory address of the virtual page.High high virtual memory address of the virtual page

The Command File

The command file for the simulator specifies a sequence of memory instructions to be per-formed. Each instruction is either a memory READ or WRITE operation, and includes a virtual memory address to be read or written. Depending on whether the virtual page for the address is present in physical memory, the operation will succeed, or, if not, a page fault will occur.

Operations on Virtual MemoryThere are two operations one can carry out on pages in memory: READ and WRITE. The format for each command is operation addressor operation randomwhere operation is READ or WRITE, and address is the numeric virtual memory address, optionally preceeded by one of the radix keywords bin, oct, or hex. If no radix is supplied, the number is assumed to be decimal. The keyword random will generate a random virtual memory address (for those who want to experiment quickly) rather than having to type an address.

For example, the sequence

READ bin 01010101WRITE bin 10101010READ random

WRITE randomcauses the virtual memory manager to:

1. read from virtual memory address 85 2. write to virtual memory address 170 3. read from some random virtual memory address 4. write to some random virtual memory address

Sample Command File

The "commands" input file looks like this:

// Enter READ/WRITE commands into this file// READ // WRITE READ bin 100READ 19WRITE hex CC32READ bin 100000000000000READ bin 100000000000000WRITE bin 110000000000001WRITE random

The Configuration FileThe configuration file memory.conf is used to specify the the initial content of the virtual memory map (which pages of virtual memory are mapped to which pages in physical memory) and provide other configuration information, such as whether operation should be logged to a file.

Setting Up the Virtual Memory Map

The memset command is used to initialize each entry in the virtual page map. memset is followed by six integer values:

1. The virtual page # to initialize 2. The physical page # associated with this virtual page (-1 if no page assigned) 3. If the page has been read from (R) (0=no, 1=yes) 4. If the page has been modified (M) (0=no, 1=yes) 5. The amount of time the page has been in memory (in ns) 6. The last time the page has been modified (in ns)

The first two parameters define the mapping between the virtual page and a physical page, if any. The last four parameters are values that might be used by a page replacement algorithm.

For example,

memset 34 23 0 0 0 0specifies that virtual page 34 maps to physical page 23, and that the page has not been read or

modified.

Note:

Each physical page should be mapped to exactly one virtual page. The number of virtual pages is fixed at 64 (0..63). The number of physical pages cannot exceed 64 (0..63). If a virtual page is not specified by any memset command, it is assumed that the page is

not mapped.

Other Configuration File Options

There are a number of other options which can be specified in the configuration file. These are summarized in the table below.

Keyword Values Description enable_logging true

false Whether logging of the operations should be enabled. If logging is enabled, then the program writes a one-line message for each READ or WRITE operation. By default, no logging is enabled. See also the log_file option.

log_file trace-file-name

The name of the file to which log messages should be written. If no filename is given, then log messages are written to stdout. This option has no effect if enable_logging is false or not specified.

pagesize npower p

The size of the page in bytes as a power of two. This can be given as a decimal number which is a power of two (1, 2, 4, 8, etc.) or as a power of two using the power keyword. The maximum page size is 67108864 or power 26. The default page size is power 26.

addressradix n The radix in which numerical values are displayed. The default radix is 2 (binary). You may prefer radix 8 (octal), 10 (decimal), or 16 (hexadecimal).

Sample Configuration File

The "memory.conf" configuration file looks like this:

// memset virt page # physical page # R (read from) M (modified) inMemTime (ns) lastTouchTime (ns)memset 0 0 0 0 0 0 memset 1 1 0 0 0 0 memset 2 2 0 0 0 0 memset 3 3 0 0 0 0 memset 4 4 0 0 0 0 memset 5 5 0 0 0 0 memset 6 6 0 0 0 0 memset 7 7 0 0 0 0 memset 8 8 0 0 0 0 memset 9 9 0 0 0 0 memset 10 10 0 0 0 0

memset 11 11 0 0 0 0 memset 12 12 0 0 0 0 memset 13 13 0 0 0 0 memset 14 14 0 0 0 0 memset 15 15 0 0 0 0 memset 16 16 0 0 0 0 memset 17 17 0 0 0 0 memset 18 18 0 0 0 0 memset 19 19 0 0 0 0 memset 20 20 0 0 0 0 memset 21 21 0 0 0 0 memset 22 22 0 0 0 0 memset 23 23 0 0 0 0 memset 24 24 0 0 0 0 memset 25 25 0 0 0 0 memset 26 26 0 0 0 0 memset 27 27 0 0 0 0 memset 28 28 0 0 0 0 memset 29 29 0 0 0 0 memset 30 30 0 0 0 0 memset 31 31 0 0 0 0

// enable_logging 'true' or 'false'// When true specify a log_file or leave blank for stdoutenable_logging true

// log_file // Where is the name of the file you want output// to be print to.log_file tracefile

// page size, defaults to 2^14 and cannot be greater than 2^26// pagesize or <'power' num (base 2)>pagesize 16384

// addressradix sets the radix in which numerical values are displayed// 2 is the default value// addressradix addressradix 16

// numpages sets the number of pages (physical and virtual)// 64 is the default value// numpages must be at least 2 and no more than 64// numpages numpages 64

The Output File

The output file contains a log of the operations since the simulation started (or since the last re-set). It lists the command that was attempted and what happened as a result. You can review this file after executing the simulation.

The output file contains one line per operation executed. The format of each line is:

command address ... statuswhere:

command is READ or WRITE, address is a number corresponding to a virtual memory address, and status is okay or page fault.

Sample OutputThe output "tracefile" looks something like this: READ 4 ... okayREAD 13 ... okayWRITE 3acc32 ... okayREAD 10000000 ... okayREAD 10000000 ... okayWRITE c0001000 ... page faultWRITE 2aeea2ef ... okay

Suggested Exercises

1. Create a command file that maps any 8 pages of physical memory to the first 8 pages of virtual memory, and then reads from one virtual memory address on each of the 64 virtual pages. Step through the simulator one operation at a time and see if you can predict which virtual memory addresses cause page faults. What page replacement algorithm is being used?

2. Modify replacePage() in PageFault.java to implement a round robin page replacement algo-rithm (i.e., first page fault replaces page 0, next one replaces page 1, next one replaces page 2, etc.).

3. Modify replacePage() in PageFault.java to implement a least recently used (LRU) page re-placement algorithm.