Operator Instructions Once the program is running the operator c.docx

Operator Instructions
Once the program is running the operator can enter one of four
characters described below.
1. Q: Executes a line of instruction.
2. U: Unblock the first simulated process in blocked queue.
3. P: Print the current state of the system.
4. T: Print the average turnaround time, and terminate the
system.
The program will prompt the user/operator and wait for input.
On receiving a Q command, the process manager executes the
next instruction of the currently running simulated process,
increments program counter value (except for F or R
instructions), increments Time, and then performs scheduling.
Note that scheduling may involve performing context switching.
On receiving a U command, the process manager moves the first
simulated process in the blocked queue to the ready state queue
array.
On receiving a P command, the process manager spawns a new
reporter process.
On receiving a T command, the process manager first spawns a
reporter process and then terminates after termination of the
reporter process.
The simulated process program consists of a sequence of
instructions will initiate the program . There are seven types of
instructions as follows:
1. S n: Set the value of the integer variable to n, where n is an
integer.
2. A n: Add n to the value of the integer variable, where n is an
integer.
3. D n: Subtract n from the value of the integer variable, where
n is an integer.
4. B: Block this simulated process.
5. E: Terminate this simulated process.
6. F n: Create a new (simulated) process. The new (simulated)

process is an exact copy of the parent (simulated) process. The
new (simulated) process executes from the instruction
immediately after this (F) instruction, while the parent
(simulated) process continues its execution n instructions after
the next instruction.
7. R filename: Replace the program of the simulated process
with the program in the file filename, and set program counter
to the first instruction of this new program.
Process Management Simulation
The objective of this program is to simulate four process
management functions: process creation, replacing the current
process image with a new process image, process state
transition, and process scheduling.
This simulation exercise consists of three processes running on
a Linux environment: commander, process manager, and
reporter. There is one commander process (this is the process
that starts your simulation), one process manager process that is
created by the commander process, and a number of reporter
processes that get created by the process manager, as needed.
1. Commander Process:
The commander process first creates a pipe and then the process
manager process. It then repeatedly reads commands from the
standard input and passes them to the process manager process
via the pipe. The commander process accepts four commands:
1. Q: End of one unit of time.
system.
Command T can only be executed once.
1.1 Simulated Process:
Process management simulation manages the execution of
simulated processes. Each simulated process is comprised of a
program that manipulates the value of a single integer variable.

Thus the state of a simulated process at any instant is comprised
of the value of its integer variable and the value of its program
counter.
A simulated process™ program consists of a sequence of
instructions. There are seven types of instructions as follows:
integer.
integer.
n is an integer.
An example of a program for a simulated process is as follows:
S 1000
A 19
A 20
D 53
A 55
F 1
R file_a
F 1
R file_b
F 1
R file_c
F 1
R file_d

F 1
R file_e
E
The program of a simulated process is stored in an array, with
one array entry for each instruction.
2. Process Manager Process:
The process manager process simulates four process
management functions: creation of new (simulated) processes,
replacing the current process image of a simulated process with
a new process image, management of process state transitions,
and process scheduling. In addition, it spawns a reporter process
whenever it needs to print out the state of the system.
The process manager creates the first simulated process
(process ID = 0) program from an input file (filename: init).
This is the only simulated process created by the process
manager on its own. All other simulated processes are created in
response to the execution of the F instruction (read from the
simulated processes).
2.1 Data structures:
The process manager maintains six data structures: Time, Cpu,
PcbTable, ReadyState, BlockedState, and RunningState.
1. Time is an integer variable initialized to zero.
2. Cpu is used to simulate the execution of a simulated process
that is in running state. It should include data members to store
a pointer to the program array, current program counter value,
integer value, and time slice of that simulated process. In
addition, it should store the number of time units used so far in
the current time slice.
3. PcbTable is an array with one entry for every simulated
process that hasn't finished its execution yet. Each entry should
include data members to store process id, parent process id, a
pointer to program counter value (initially 0), integer value,
priority, state, start time, and CPU time used so far.
4. ReadyState stores all simulated processes (PcbTable indices)
that are ready to run. This can be implemented using a queue or
priority queue data structure.

5. BlockedState stores all processes (PcbTable indices) that are
currently blocked. This can be implemented using a queue data
structure.
6. RunningState stores the PcbTable index of the currently
running simulated process.
2.2 Processing input commands:
After creating the first process and initializing all its data
structures, the process manager repeatedly receives and
processes one command at a time from the commander process
(read via the pipe). On receiving a Q command, the process
manager executes the next instruction of the currently running
simulated process, increments program counter value (except
for F or R instructions), increments Time, and then performs
scheduling. Note that scheduling may involve performing
context switching.
array. On receiving a P command, the process manager spawns a
new reporter process. On receiving a T command, the process
manager first spawns a reporter process and then terminates
after termination of the reporter process. The process manager
ensures that no more than one reporter process is running at any
moment.
2.3 Executing simulated processes:
The process manager executes the next instruction of the
currently running simulated process on receiving a Q command
from the commander process. Note that this execution is
completely confined to the Cpu data structure, i.e., PcbTable is
not accessed.
Instructions S, A, and D update the integer value stored in Cpu.
Instruction B moves the currently running simulated process to
the blocked state and moves a process from the ready state to
the running state. This will result in a context switch.
Instruction E terminates the currently running simulated
process, frees up all memory (e.g., program array) associated
with that process and updates the PcbTable. A simulated process

from the ready state is moved to running state. This also results
in a context switch.
Instruction F results in the creation of a new simulated process.
A new entry is created in the PcbTable for this new simulated
process. A new (unique) process ID is assigned and the parent
process ID is the process ID of the parent simulated process.
Start time is set to the current Time value and CPU time used so
far is set to 0. The program array and integer value of the new
simulated process are a copy of the program array and integer
value of the parent simulated process. The new simulated
process has the same priority as the parent simulated process.
The program counter value of the new simulated process is set
to the instruction immediately after the F instruction, while the
program counter value of the parent simulated process is set to
n instructions after the next instruction (instruction immediately
after F). The new simulated process is created in the ready state.
Finally, the R instruction results in replacing the process image
of the currently running simulated process. Its program array is
overwritten by the code in file filename, program counter value
is set to 0, and integer value is undefined. Note that all these
changes are made only in the Cpu data structure. Process ID,
parent process ID, start time, CPU time used so far, state, and
priority remain unchanged.
2.4 Scheduling
The process manager also implements a scheduling policy. You
may experiment with a scheduling policy of multiple queues
with priority classes. In this policy, the first simulated process
(created by the process manager) starts with priority 0 (highest
priority). There are a maximum of four priority classes. Time
slice (quantum size) for priority class 0 is 1 unit of time; time
slice for priority class 1 is 2 units of time; time slice for
priority class 2 is 4 units of time; and time slice for priority
class 3 is 8 units of time. If a running process uses its time slice
completely, it is preempted and its priority is lowered. If a
running process blocks before its allocated quantum expires, its
priority is raised.

3. Reporter Process
The reporter process prints the current state of the system on the
standard output and then terminates. The output from the
reporter process appears as follows:
*****************************************************
***********
The current system state is as follows:
*****************************************************
***********
CURRENT TIME: time
RUNNING PROCESS:
pid, ppid, priority, value, start time, CPU time used so far
BLOCKED PROCESSES:
Queue of blocked processes:
¦
PROCESSES READY TO EXECUTE:
Queue of processes with priority 0:
pid, ppid, value, start time, CPU time used so far
¦
¦
*****************************************************
***********
2.4 Scheduling
The process manager also implements a scheduling policy. In
this policy, the first simulated process (created by the process
manager) starts with priority 0 (highest priority). There are a
maximum of four priority classes. Time slice (quantum size) for
priority class 0 is 1 unit of time; time slice for priority class 1
is 2 units of time; time slice for priority class 2 is 4 units of
time; and time slice for priority class 3 is 8 units of time. If a

running process uses its time slice completely, it is preempted
and its priority is lowered. If a running process blocks before its
allocated quantum expires, its priority is raised.
3. Reporter Process
*****************************************************
***********
*****************************************************
***********
CURRENT TIME: time
RUNNING PROCESS:
BLOCKED PROCESSES:
¦
¦
¦
*****************************************************
***********
ECET360 Week 3 Lab Robert Weymouth
// ECET360 Lab 3

// Comment out the two lines below to disable the pipe() and
fork() behavior of
// the program. This may make debugging much easier since
there is only one
// process to debug.
// #define ENABLE_COMMANDER
// #define ENABLE_REPORTER
#include <cctype> // for toupper()
#include <cstdlib> // for EXIT_SUCCESS and EXIT_FAILURE
#include <cstring> // for strerror()
#include <cerrno> // for errno
#include <deque> // for deque (used for ready and blocked
queues)
#include <fstream> // for ifstream (used for reading simulated
process programs)
#include <iostream> // for cout, endl, and cin
#include <sstream> // for stringstream (for parsing simulated
process programs)
#include <sys/wait.h> // for wait()
#include <unistd.h> // for pipe(), read(), write(), close(), fork(),
and _exit()
#include <vector> // for vector (used for PCB table)
using namespace std;
class Instruction {
public:
char operation;
int intArg;
string stringArg;
};
class Cpu {
public:
vector<Instruction> *pProgram;

int programCounter;
int value;
int timeSlice;
int timeSliceUsed;
};
enum State {
STATE_READY,
STATE_RUNNING,
STATE_BLOCKED
};
class PcbEntry {
public:
int processId;
int parentProcessId;
vector<Instruction> program;
unsigned int programCounter;
int value;
unsigned int priority;
State state;
unsigned int startTime;
unsigned int timeUsed;
};
// The number of valid priorities.
#define NUM_PRIORITIES 4
// An array that maps priorities to their allotted time slices.
static const unsigned int
PRIORITY_TIME_SLICES[NUM_PRIORITIES] = {
1,
2,
4,
8
};

unsigned int timestamp = 0;
Cpu cpu;
// For the states below, -1 indicates empty (since it is an invalid
index).
int runningState = -1; // The index of the running process in the
PCB table.
// readyStates is an array of queues. Each queue holds PCB
indices for ready processes
// of a particular priority.
deque<int> readyStates[NUM_PRIORITIES];
deque<int> blockedState; // A queue fo PCB indices for blocked
processes.
// In this implementation, we'll never explicitly clear PCB
entries and the
// index in the table will always be the process ID. These
choices waste memory,
// but since this program is just a simulation it the easiest
approach.
// Additionally, debugging is simpler since table slots and
process IDs are
// never re-used.
vector<PcbEntry *> pcbTable;
double cumulativeTimeDiff = 0;
int numTerminatedProcesses = 0;
// Sadly, C++ has no built-in way to trim strings:
string &trim(string &argument) {
string whitespace(" tnvfr");
size_t found = argument.find_last_not_of(whitespace);
if (found != string::npos) {
argument.erase(found + 1);

argument.erase(0,
argument.find_first_not_of(whitespace));
} else {
argument.clear(); // all whitespace
}
return argument;
}
bool createProgram(const string &filename, vector<Instruction>
&program) {
ifstream file;
int lineNum = 0;
program.clear();
file.open(filename.c_str());
if (!file.is_open()) {
cout << "Error opening file " << filename << endl;
return false;
}
while (file.good()) {
string line;
getline(file, line);
trim(line);
if (line.size() > 0) {
Instruction instruction;
instruction.operation = toupper(line[0]);
instruction.stringArg = trim(line.erase(0, 1));
stringstream argStream(instruction.stringArg);
switch (instruction.operation) {

case 'S': // Integer argument.
case 'A': // Integer argument.
case 'D': // Integer argument.
case 'F': // Integer argument.
if (!(argStream >> instruction.intArg)) {
cout << filename << ":" << lineNum
<< " - Invalid integer argument "
<< instruction.stringArg << " for "
<< instruction.operation << " operation"
<< endl;
file.close();
return false;
}
break;
case 'B': // No argument.
case 'E': // No argument.
break;
case 'R': // String argument.
// Note that since the string is trimmed on both
ends,
// filenames with leading or trailing whitespace
(unlikely)
// will not work.
if (instruction.stringArg.size() == 0) {
<< " - Missing string argument" << endl;
file.close();
return false;
}
break;
default:
<< " - Invalid operation, " <<
instruction.operation
<< endl;

file.close();
return false;
}
program.push_back(instruction);
}
lineNum++;
}
file.close();
return true;
}
// Implements the S operation.
void set(int value) {
cpu.value = value;
cout << "Set CPU value to " << value << endl;
}
// Implements the A operation.
void add(int value) {
cpu.value += value;
cout << "Incremented CPU value by " << value << endl;
}
// Implements the D operation.
void decrement(int value) {
cpu.value -= value;
cout << "Decremented CPU value by " << value << endl;
}

// Performs scheduling.
void schedule(void)
{
cout <<"cpu timeslice used " <<cpu.timeSliceUsed<<endl;
cout <<"cpu timeslice " <<cpu.timeSlice<<endl;
if ((runningState != -1) && (cpu.timeSliceUsed >=
cpu.timeSlice)) {
// The currently running process consumed its entire time
slice.
PcbEntry *pcbEntry = pcbTable[runningState];
// Lower the process priority.
if (pcbEntry->priority >= 0 && pcbEntry->priority <
(NUM_PRIORITIES - 1)) {
pcbEntry->priority++;
}
readyStates[pcbEntry->priority].push_back(runningState);
cout << "Process exceeded time slice, pid = " <<
pcbEntry->processId <<
endl;
pcbEntry->state = STATE_READY;
pcbEntry->programCounter = cpu.programCounter;
pcbEntry->value = cpu.value;
pcbEntry->timeUsed += cpu.timeSliceUsed;
runningState = -1;
}
if (runningState != -1) {
return;
}

// Get a new process to run, if possible, from the ready queue
in priority
// order.
for (int index = 0; index < NUM_PRIORITIES; index++) {
if (!readyStates[index].empty()) {
runningState = readyStates[index].front();
readyStates[index].pop_front();
break;
}
}
// Make sure there is a process to run.
if (runningState != -1) {
// Mark the process as running.
pcbEntry->state = STATE_RUNNING;
// Update the CPU with new PCB entry details.
cpu.pProgram = &pcbEntry->program;
cpu.programCounter = pcbEntry->programCounter;
cpu.value = pcbEntry->value;
cpu.timeSlice = PRIORITY_TIME_SLICES[pcbEntry-
>priority];
cpu.timeSliceUsed = 0;
cout << "Process running, pid = " << pcbEntry->processId
<< endl;
}
}
// Implements the B operation.
void block() {
// TODO: Raise the process priority (remember since the

highest priority is zero,
// you actually have to decrement the priority to raise it).
Also make sure to
// not decrement the priority below zero.
if (pcbEntry->priority > 0 && pcbEntry->priority <=
(NUM_PRIORITIES - 1)) {
pcbEntry->priority--;
}
blockedState.push_back(runningState);
pcbEntry->state = STATE_BLOCKED;
runningState = -1;
cout << "Blocked process, pid = " << pcbEntry->processId
<< endl;
}
// Implements the E operation.
void end() {
// Add 1 to account for the time to execute the E operation.
cumulativeTimeDiff += (double) (timestamp + 1 - pcbEntry-
>startTime);
numTerminatedProcesses++;
cout << "Ended process, pid = " << pcbEntry->processId <<
endl;
runningState = -1;
}

// Implements the F operation.
void fork(int value) {
int pcbIndex = (int) pcbTable.size();
PcbEntry *runningPcbEntry = pcbTable[runningState];
PcbEntry *pcbEntry = new PcbEntry();
pcbEntry->processId = pcbIndex;
pcbEntry->parentProcessId = runningPcbEntry->processId;
pcbEntry->program = runningPcbEntry->program;
pcbEntry->priority = runningPcbEntry->priority;
pcbEntry->startTime = timestamp + 1;
pcbEntry->timeUsed = 0;
pcbTable.push_back(pcbEntry);
// TODO: Update the line below to use the correct
readyStates queue.
readyStates[0].push_back(pcbIndex);
cout << "Forked new process, pid = " << pcbEntry-
>processId << endl;
if ((value < 0) ||
(cpu.programCounter + value >= cpu.pProgram-
>size())) {
cout << "Error executing F operation, ending parent
process" << endl;
end();
}
cpu.programCounter += value;

}
// Implements the R operation.
void replace(string &argument) {
if (!createProgram(argument, *cpu.pProgram)) {
cout << "Error executing R operation, ending process" <<
endl;
end();
return;
}
cpu.programCounter = 0;
cout << "Replaced process with " << argument << ", pid = "
<< pcbTable[runningState]->processId << endl;
}
// Implements the Q command.
void quantum() {
Instruction instruction;
if (runningState == -1) {
cout << "No processes are running" << endl;
++timestamp;
return;
}
if (cpu.programCounter < cpu.pProgram->size()) {
instruction = (*cpu.pProgram)[cpu.programCounter];
cpu.programCounter++;
} else {
cout << "End of program reached without E operation" <<
endl;
instruction.operation = 'E';

}
switch (instruction.operation) {
case 'S':
set(instruction.intArg);
break;
case 'A':
add(instruction.intArg);
break;
case 'D':
decrement(instruction.intArg);
break;
case 'B':
block();
break;
case 'E':
end();
break;
case 'F':
fork(instruction.intArg);
break;
case 'R':
replace(instruction.stringArg);
break;
}
timestamp++;
// TODO: Increment cpu.timeSliceUsed.
cpu.timeSliceUsed = cpu.timeSliceUsed + 1;
schedule();
}
// Implements the U command.
void unblock() {
if (!blockedState.empty()) {

int pcbIndex = blockedState.front();
PcbEntry *pcbEntry = pcbTable[pcbIndex];
blockedState.pop_front();
// TODO: Update the line below to use the correct
readyStates queue.
readyStates[0].push_back(pcbIndex);
cout << "Unblocked process, pid = " << pcbEntry-
>processId << endl;
}
schedule();
}
// Implements the P command.
void print() {
#ifdef ENABLE_REPORTER
pid_t pid;
pid = fork();
if (pid == -1) {
cout << "fork:" << strerror(errno) << endl;
return;
}
if (pid != 0) {
// Wait for the reporter process to exit.
wait(NULL);
return;
}
#endif
// TODO: Implement all of the printing logic.

#ifdef ENABLE_REPORTER
_exit(EXIT_SUCCESS);
#endif
}
// Function that implements the process manager.
int runProcessManager(int fileDescriptor) {
PcbEntry *pcbEntry = new PcbEntry();
// Attempt to create the init process.
if (!createProgram("init", pcbEntry->program)) {
return (int) EXIT_FAILURE;
}
pcbEntry->processId = (int) pcbTable.size();
pcbEntry->parentProcessId = -1;
pcbEntry->programCounter = 0;
pcbEntry->value = 0;
pcbEntry->priority = 0;
pcbEntry->state = STATE_RUNNING;
pcbEntry->startTime = 0;
pcbEntry->timeUsed = 0;
pcbTable.push_back(pcbEntry);
runningState = pcbEntry->processId;
cout << "Running init process, pid = " << pcbEntry-
>processId << endl;
cpu.pProgram = &(pcbEntry->program);
cpu.programCounter = pcbEntry->programCounter;
cpu.value = pcbEntry->value;

timestamp = 0;
double avgTurnaroundTime = 0;
// Loop until a 'T' is read, then terminate.
char ch;
do {
// Read a command character from the pipe.
if (read(fileDescriptor, &ch, sizeof (ch)) != sizeof (ch)) {
// Assume the parent process exited, breaking the pipe.
break;
}
// Ignore whitespace characters.
if (isspace(ch)) {
continue;
}
// Convert commands to a common case so both lower and
uppercase
// commands can be used.
ch = toupper(ch);
switch (ch) {
case 'Q':
quantum();
break;
case 'U':
unblock();
break;
case 'P':
print();
break;
case 'T':
if (numTerminatedProcesses != 0) {

avgTurnaroundTime = cumulativeTimeDiff
/ (double) numTerminatedProcesses;
}
cout << "The average turnaround time is " <<
avgTurnaroundTime
<< "." << endl;
break;
default:
cout << "Unknown command, " << ch << endl;
}
} while (ch != 'T');
// Cleanup any remaining PCB entries.
for (vector<PcbEntry *>::iterator it = pcbTable.begin();
it != pcbTable.end(); it++) {
delete *it;
}
pcbTable.clear();
return EXIT_SUCCESS;
}
// Main function that implements the commander.
int main(int argc, char *argv[]) {
#ifdef ENABLE_COMMANDER
int pipeDescriptors[2];
pid_t processMgrPid;
char ch;
int result;
// Create a pipe.
if (pipe(pipeDescriptors) == -1) {
// Print an error message to help debugging.
cout << "pipe: " << strerror(errno) << endl;
return EXIT_FAILURE;

}
// Create the process manager process.
processMgrPid = fork();
if (processMgrPid == -1) {
// Print an error message to help debugging.
cout << "fork: " << strerror(errno) << endl;
return EXIT_FAILURE;
}
if (processMgrPid == 0) {
// The process manager process is running.
// Close the unused write end of the pipe for the process
manager
// process.
close(pipeDescriptors[1]);
// Run the process manager.
result = runProcessManager(pipeDescriptors[0]);
// Close the read end of the pipe for the process manager
process (for
// cleanup purposes).
_exit(result);
} else {
// The commander process is running.
// Close the unused read end of the pipe for the
commander process.
// Loop until a 'T' is written or until the pipe is broken.
do {

// Read a command character from the standard input.
cin >> ch;
// Pass commands to the process manager process via
the pipe.
if (write(pipeDescriptors[1], &ch, sizeof (ch)) != sizeof
(ch)) {
// Assume the child process exited, breaking the pipe.
break;
}
} while (ch != 'T');
// Wait for the process manager to exit.
wait(&result);
// Close the write end of the pipe for the commander
process (for
// cleanup purposes).
}
return result;
#else
// Run the Process Manager directly.
return runProcessManager(fileno(stdin));
#endif
}
Operator Instructions
Once the program is running the operator can enter one of four
characters described below.
1. Q: Executes a line of instruction.

system.
The program will prompt the user/operator and wait for input.
On receiving a Q command, the process manager executes the
next instruction of the currently running simulated process,
increments program counter value (except for F or R
instructions), increments Time, and then performs scheduling.
Note that scheduling may involve performing context switching.
array.
On receiving a P command, the process manager spawns a new
reporter process.
On receiving a T command, the process manager first spawns a
reporter process and then terminates after termination of the
reporter process.
The simulated process program consists of a sequence of
instructions will initiate the program . There are seven types of
instructions as follows:
integer.
integer.
n is an integer.

Page 8 of 25
Lab 3 of 7: Process Management Simulation (50 Points)
Note!
Submit your assignment to the Dropbox located on the silver tab
at the top of this page.
(See the Syllabus section "Due Dates for Assignments &
Exams" for due dates.)
iLAB ACCESS
Accessing the iLab Environment
For information about accessing your iLab please refer to the
iLab section under Course Home
iLAB OVERVIEW
Scenario/Summary
Process Management Simulation (Part 3 of 3)
The objective of this three section lab is to simulate four
process management functions: process creation, replacing the
current process image with a new process image, process state
transition, and process scheduling.
This lab will be due over the first three weeks of this course.
The commander process program is due in Week 1. This
program will introduce the student to system calls and other
basic operating system functions. The process manager
functions “ process creation, replacing the current process
image with a new process image and process state transition “
are due in Week 2. The scheduling section of the process
manager is due in Week 3.
You will use Linux system calls such as fork( ), exec(), wait( ),
pipe( ), and sleep( ). Read man pages of these system calls for
details.
This simulation exercise consists of three processes running on
a Linux environment: commander, process manager, and

reporter. There is one commander process (this is the process
that starts your simulation), one process manager process that is
created by the commander process, and a number of reporter
processes that get created by the process manager, as needed.
system.
counter.
integer.
integer.
n is an integer.

S 1000
A 19
A 20
D 53
A 55
F 1
R file_a
F 1
R file_b
F 1
R file_c
F 1
R file_d
F 1
R file_e
E
You may store the program of a simulated process in an array,
with one array entry for each instruction.

structure.
context switching.

moment.
not accessed.
program counter value of the parent simulated process is set to
n instructions after the next instruction (instruction immediately
after F). The new simulated process is created in the ready state.

2.4 Scheduling
priority is raised.
3. Reporter Process
*****************************************************
***********
*****************************************************
***********
CURRENT TIME: time
RUNNING PROCESS:
BLOCKED PROCESSES:
¦

¦
¦
*****************************************************
***********
Deliverables
You will submit three separate files to the dropbox for Week 3:
1. C or C++ program (source code)
2. Executable file (object), and
3. Instructions to execute the program
Required Software
Connect to the iLab here
iLAB STEPS
Process Manager Scheduling (25 points)
Back to Top
The programs for the process scheduling and the reporter
process are due this week. These programs are to be written in
C or C++ programming languages on a Linux environment.
IMPORTANT: Please make sure that any questions or
clarification about these labs are addressed early.
2.4 Scheduling

priority is raised.
Reporter Process Requirements (25 points)
Back to Top
3. Reporter Process
*****************************************************
***********
*****************************************************
***********
CURRENT TIME: time
RUNNING PROCESS:
BLOCKED PROCESSES:
¦
¦
¦
*****************************************************
***********

Lab 7 of 7: Formal Documentation (50 Points)
Note!
Submit your assignment to the Dropbox located on the silver tab
at the top of this page.
(See the Syllabus section "Due Dates for Assignments &
Exams" for due dates.)
iLAB ACCESS
Accessing the iLab Environment
For information about accessing your iLab please refer to the
iLab section under Course Home
iLAB OVERVIEW
Scenario/Summary
Prepare formal documentation of the code for the process
management simulation labs for Weeks 1 thru 3. You need an
install and README file, a user guide, a system programming
guide, and manual pages.
Deliverables
You will submit four separate files to the dropbox for Week 7:
1. An Install and README file
2. A User Guide
3. A System Programming Guide
4. Manual pages
Required Software
Connect to the iLab here
iLAB STEPS
Formal Documentation (50 points)
Back to Top
The documents required must be in MS Word 2007 format.
Technical content is essential for these documents as well as
grammar, spelling, and organization.

system.
counter.
integer.
integer.
n is an integer.
S 1000
A 19
A 20

D 53
A 55
F 1
R file_a
F 1
R file_b
F 1
R file_c
F 1
R file_d
F 1
R file_e
E
You may store the program of a simulated process in an array,
with one array entry for each instruction.

structure.
context switching.
moment.

not accessed.
program counter value of the of the parent simulated process is
set to n instructions after the next instruction (instruction
immediately after F). The new simulated process is created in
the ready state.
2.4 Scheduling

priority is raised.
3. Reporter Process
*****************************************************
***********
*****************************************************
***********
CURRENT TIME: time
RUNNING PROCESS:
BLOCKED PROCESSES:
¦
¦
¦

*****************************************************
***********
Here is what I expect for lab7:
1. An Install and README file: A single file that gives a brief
description of the program, how to install it, how to execute it
(you don't really need to explain commands etc, just how to
start the program), and maybe references to any other relevant
information (i.e. for more information consult the user guide).
The overall guidance here is: keep it short and to the point.
2. A User Guide: You need to describe the program's behavior
(what the user should expect to see), what the commands are
and their purposes. You probably want to describe the format of
the "program" files that the simulator runs. Almost all the
information you need is on the iLab page itself, except you
should describe any thing about your program that may be
special, different, or not immediately obvious to a user. The
overall guidance here is to accurately describe how to use all
aspects of the program without talking about how the program
works or is implemented (unless it is absolutely essential to
understand how to use the program).
3. A System Programming Guide: This guide will explain the
design and structure of the program itself. Describe how it
works on an internal level. This is a guide a programmer might
use, so you want to consider the use cases that relate to a
programmer. What if a programmer wanted to add a new
command? How about a new program operation? etc.. The
information contained within should give a programmer a good
idea of which parts of the program provide specific
functionality, and how that functionality is implemented. You
don't want to go down to the level of describing the code itself
in words, but you do want to describe any important algorithms
in detail, and at least generalize how things work. The overall

guidance here is to leave out details about how to run or use the
program, and just talk about how the program actually does its
job.
4. Manual pages: This is mostly going to be a reformatting of
the Users Guide. You should follow the format of a typical
Unix/Linux man page (google around to find some examples). I
would include most or all of the things in the Users Guide.

Operator Instructions Once the program is running the operator c.docx

Recommended

Recommended

More Related Content

Similar to Operator Instructions Once the program is running the operator c.docx

Similar to Operator Instructions Once the program is running the operator c.docx (20)

More from cherishwinsland

More from cherishwinsland (20)

Recently uploaded

Recently uploaded (20)

Operator Instructions Once the program is running the operator c.docx