RyanRemson - People.vcu.edu

yakconspiracySoftware and s/w Development

Dec 14, 2013 (3 years and 7 months ago)

73 views

Group ESOS (Extra Sensory Operating System)

(Logan Byam, Jeremy Cooper, Jody Des Roches, Ryan Remson)

CMSC312 Project Proposal

05 March 2005


Hardware:

Single CPU

16KB RAM, with Virtual Memory

Quantum Size = 10 cycles


Interface:

Programs may be loaded/exe
cuted via command line or graphical interface

Each program is a sequence of operations in a .txt file


Each line within program will consist of one of the following:



CALCULATION <
n
>: requires
n

CPU cycles



I/O <
id
>: simulates an I/O operation on a devic
e named
id

(25 cycles <= I/O process <= 50 cycles)



OUT <
message
>: prints
message

to console



MEMORY <
size
>: memory space required {2KB <=
size

<= 10KB}

Job files must be loaded and executed. Each job file contains:


RESET:

sets everything back to zero


<
n
> LOAD <
filename
>:

n

is arrival time of program (in cycles
and

non
-
negative),
filename

is name of file
containing “program”


EXE: starts simulation. Simulator decides when to load a specific program to execute.


When a process is loaded, a PCB (
process
control
block) is created for it. PCB will be a class within our code.


States to be tracked throughout process lifespan:
New, Running, Blocked, Ready, Exit


Process Scheduling

Our group has chosen to use Round Robin Processing for Process Scheduling, due
to the following:


Uses quantums (prevents starvation)


Is preemptive (due to quantums)


Ready Queue is “circular FCFS”


Memory Management

Not enough material has been presented in class to make a decision on our final approach to Memory Management,
howeve
r, we have elected to use
swapping

for medium
-
term scheduling. Once Virtual Memory is covered in lecture, we
may elect to go in that direction for our project.


Interrupt Handling, including Context Switches

By definition, interrupts are generated wheneve
r input is ready, output is completed, or an error has occurred. Our
interrupt handler will be able to distinguish between types of interrupts and the devices associated with I/O requests. The
Interrupt Handler (IH) acts as the sole go
-
between between the
various Waiting Queues, the Ready Queue, and the CPU.
The Waiting Queues and the Ready Queue will be, by design, unaware of each other, or their respective states. The IH
handles the transfers between the Waiting Queues and the Ready Queue, as well as betw
een the CPU and the Waiting
Queues. Error interrupts terminate their specific process(es).

Context Switching will act to maintain (save) the PCB settings of a process as it passes through specific states on its route

to completion.



Our Proposal


Our O
S is a single
-
user system with no message passing. This eliminates any need for memory sharing. Any Protection
System would be handled by the Memory Management System. There is no Secondary
-
Storage Management, no
Networking, and no File Management.


We wil
l use Process Management, Main Memory Management, I/O System Management, and a Command Interpreter
System. Process Management will control how and when processes are run. This includes transition from Job Queue to
Ready Queue (long
-
term scheduling), Ready
Queue to Run Queue (short
-
term scheduling), Run Queue to Waiting Queue
(when applicable), Run Queue to Ready Queue, Run Queue to Exit Queue, and Waiting Queue to Ready Queue. The
Round Robin algorithm will be instituted for short
-
term processing. We have c
hosen this primarily because it is
not

priority
based, which gives each process an equal amount of CPU time. This virtually negates the possibility of starvation. Other
scheduling algos may possess the
ability

to reduce starvation with aging, but the cost
is increased complexity. Long
-
term
scheduling is primarily FIFO


every program file would immediately go to the Ready Queue in the order received
If then,
you do not need any long term scheduler. The purpose of long term scheduler is to control the numbe
r of process in the
system.
. When handling Job files, the long
-
term scheduler will send the programs to the Ready Queue
at their specified
arrival time
. Context Switching will act to maintain (save) the PCB settings of each process as it changes state in
and out
of the Run Queue.

What bout the relation between context switch time and quantum time



The Main Memory Management component will handle the swapping of processes in and out of Main Memory and the
Backing Store (Swap Space).

I do not know when and
why you need swaping.

This component will also handle
where

to
allocate this memory. We have elected to forego using Virtual Memory unless/until the topic is covered in lecture. While
we realize this may result in a less efficient handling of processes, wi
thout more information on Virtual Memory, we lack
the understanding necessary to implement it as part of our design. However, we reserve the right to use Virtual Memory
in our final product.

(If you want to use VM concept on your project, your group can ma
ke an appointment with me to
discuss the range and method of VM implementation on your project. I am willing to see the product.


For the sake of simplicity, the I/O System Management component will allow for three I/O devices: monitor, keyboard,
and hard
drive. Each device will possess its own Waiting Queue to allow for the simultaneous execution of processes.
Each queue will be keyed to an individual device ID number. When a request is received for a busy device, the waiting
queue will be handled in an FC
FS manner, again for simplicity. As each I/O request is completed, that process is returned
to the Ready Queue and the next process is pulled off of the Waiting Queue. Our interrupt handler will be able to
distinguish between types of interrupts and the de
vices associated with I/O requests. The Interrupt Handler (IH) will act
as the sole distributor between the various Waiting Queues, the Ready Queue, and the CPU. The Waiting Queues and the
Ready Queue will be, by design, unaware of each other, or their res
pective states. The IH will handle the transfers
between the Waiting Queues and the Ready Queue, as well as between the CPU and the Waiting Queues. Error interrupts
terminate their specific process(es).



The Command Interpreter component will allow inter
active launching of program and job files, as well as a graphical
means of tracking their progress. The user will select program files or job files from a standard File Open dialog box. The
user will see a visible update of each process’ state, the “curren
t” PCB values (including PC counter), and a listing of the
contents of each queue, as well as the state of each member of those queues.
(How many windows do you need? Are
these cascading
?)


A list of I/O devices will include visual representations of their
respective queues. A similar graphic will
display the memory map, clearly displaying which processes are in Main Memory, as well as what is contained in the
Swap Space. We intend to implement a processor timer tied to cycle count. The user will have the ab
ility to increment the
cycle count (in forward direction only), resulting in visual feedback regarding the state of all queues and processes at that

instant. The user will also have the ability to pause, restart, and reset the timer.


The “Extra Sensory” i
n our OS name refers to the fact that it will provide extensive audio feedback to its user.


In regard to how our group intends to resolve our numerous questions and concerns (which follow), our intention is to
review our professor’s answers to our queries
, then adjust our proposal as necessary. In the case of Virtual Memory in
particular, we are aggressively investigating its concepts in advance of their scheduled lecture coverage, which would
allow sufficient time to employ VM in our project should it app
ear advantageous to do so. Should we opt to do that, it is
our collective hope that our professor will continue to be an important source of information and inspiration.



Task Table & Responsible Parties



Component

% of Job

Start/Completion Dates

Respon
sible Team
Member

Short
-
Term Scheduling

20

03/05/2005

Jeremy

01

Setup of Ready Queue and Run State

02

Context Switching

03

Synchronize with cycles

Long
-
Term Scheduling

15

03/05/2005

Logan

01

Store Job File Program Elements

02

Create PCBs

03

Setup o
f Job Queue

04

Synchronize with cycles

05


Memory Management

25

03/05/2005

Jody

01

Medium
-
Term Scheduling

02

Allocate Initial Memory

03

Delete Processes from Main Memory

04

Setup of Swap Space and Main Memory

05

Synchronize with queues

I/O

15

03/0
5/2005

Logan/Jeremy

01

Interrupt Handler

02

Setup of Device Waiting Queues

03

Randomize I/O time

04

Synchronize with cycles

GUI/Command Interpreter

25

03/05/2005

Ryan/All

01

Prompt for Filename and location

02

Parse Job and Program File(s)

03

Inser
t into Long
-
Term Scheduler

04

Control cycles

05

Allow user to define cycle count

06

Display Instance Output


We realize we may find it necessary to break these broad categorizations down further as we get deeper into the project.
For now, these are the

basic assignments.

Questions and Concerns



1.

Regarding Print Messages:

Do we need to print the messages that belong to Programs within Job Files? If so, can they all be printed
on the same screen?

Yes

Do the Print Messages require I/O time (waiting queue)
?

It is your choice.

Do we need to print these messages in separate windows for each process?

Again, it is your choice of
design

2.

Regarding Memory Management:

The syllabus indicates that you won’t be covering this material until very late in the semester, p
erhaps
too late to be of use if we need to implement it in our project. Will you be covering this material earlier
now?

No. But I am willing to give enough information to implement if you want. Why don
’t you make
some time arrangement among your group memb
er and me for this.

3.

Regarding I/O & Interrupt Handling:

Do we need to write device drivers? If not, are Waiting Queues all that is necessary, and if that is the
case, is it necessary to have a separate Waiting Queue for each I/O device?

You do not need any

device
drivers

and it is not necessary to have a
separate

Queue for each I/O device. However, I recommend to
do because you need to distinguish processes waiting for different I/O events anyway.

4.

What causes the PC to be incremented, and what is the incre
ment size (1? 4? Something else?)?

It is your
design choice. However, I recommend
using

1. In reality, it will automatically increase after the CPU fetch an
instruction from the memory.

5.

Under
User Interface

in your Project Q & A, you specify that we must a
ccount for “scheduling algorithm,
memory management algorithm, etc.” What exactly does that mean? What are your expectations?

6.

The Q and A is not for this semester. That means the information in there is OLD.

7.

However, that is still useful.

8.

What I expect for

User Interface is a way to show the
functionality

of your Operating System simulator to
users. Probably, user want to see the route that a specific process shall go through. For that you may have
certain interface so
that user specifies

the process and yo
ur system show the
transitions
.

9.

User may want to see the state of the system in terms of memory, or queues that
system has

to
maintain
.

Then you need to provide some interface so
that user specifies

the contents that he/she
wants

to see

and so
on. So first
, think your self as a user of your system, enumerates all the functions you want to see

and design
some interface as unified as possible.