03-60-330-01 winter 2010 dr. robert d. kent last updated: wednesday, feb. 3, 2010 copyright ©...

03-60-330-01

Winter 2010

Dr. Robert D. Kent

Last updated: Wednesday, Feb. 3, 2010

Copyright © Robert D. Kent, Ph.D. 2010

Introductory CommentsThis set of slides is intended to provide additional

conceptual insight into the model and requirements for the course project during Winter 2010 semester.

Students are reminded that implementation requires interpretation of the model and there is considerable flexibility for each group.

These notes are not comprehensive, but they provide a fundamental basis for design.Student groups may elect to download this document and

then extend the document to reflect design and implementation goals and progress.

Copyright © Robert D. Kent, Ph,D, 2010

Introductory CommentsIt is important to keep things simple at the outset, then

add complexity as the project codes grow and are tested There is often a tendency to over-complicate so keep it

simple

These notes are not complete so it is vital to ask questions for clarification

Many aspects of the project deal with concepts and techniques that may be discussed in lectures only later in the course – it is vital to read ahead and research topics independently


Programs and ProcessesA program is written by humans in a logical form that embodies

operations and data. The essential notions in this project concern instructions and stack management as used by C language functions. A high level language, like C, is compiled into a structured form that is compatible with execution on the machine intended.

Due to the semantics of programming languages, compilers are capable of determining the logical requirements for resources. The policy of dealing with resource requests is established by the operating system. It is common to execute I/O requests by assuming they are dealt with

by the O/S directly as system level calls.The set of all logical resources required by a program is stored in a

header that is attached to the actual executable module that is the machine code translation of the original high-level program.


Programs and ProcessesThus, each program consists of some number of

instructions and a stack, each of which require a certain amount of storage space in memory, and a set of buffer storages used to transfer data to or from for each I/O device type considered.

To simplify, we consider the total code space as subdivided into an instruction space and a stack space and a single buffer for each device type.At execution time, the location of the next instruction is

required. To push and pop data frames to support function calling –

thus, the location of the stack is needed.The locations of each I/O buffer are also needed.


Programs and ProcessesThe typical file structure of a program is broken

down into the header and the loadable process code

Header

Loadable code

The header contains data describing the loadable code and resources needed (the length/size of the header is known from its first entry)

The loadable code section contains executable instructions (machine coded), data and space for stack and heap and buffers.


Programs and ProcessesLogical model of a

program is characterized byPC – program counterInstruction type

CPU I/O

SP – stack pointerStack frameStack sizeProgram size

Instruction CPU

Instruction CPU

Instruction CPU

Instruction CPU

...............

Instruction I/O

Instruction CPU

Instruction CPU

0

1

2

...

CMAX - 1

PC

SP

push

pop

Logical offset


Programs and ProcessesInstructions

CPUI/O

StacksStack frameStack size

Heap space, and I/O buffers can also be incorporated into this simple model

Instruction CPU

Instruction CPU

Instruction CPU

Instruction CPU

...............

Instruction I/O

Instruction CPU

Instruction CPU

0

1

2

...

CMAX - 1

PC

SP

push

pop

Logical offset


Programs and ProcessesSimulating a process execution may be dealt with simply

PC = randPC( args ) ; IR = randInstrType( args ) ; switch (IR) {

case 0 : interrupt_0( args ) ; break ;case 1 : interrupt_1( args ) ; break ;case 2 : interrupt _2( args ) ; break ;/* and so on for CPU and I/O instructions and also exceptions */default : break ;

}

This approach permits various assumptions and may be adapted to different designs.


Programs and ProcessesProcesses may be loaded into RAM in two basic ways,

segmentation or paging. Each of these approaches provide execution time support while improving certain aspects of memory management (with associated costs)

SegmentationRetains the logical view of the process as a single allocation

entity in memory with an assigned load point addressPaging

Splits the process codes into multiple pages of fixed length that are then loaded into fixed length frames in memory

This requires a memory mapping technique using page-frame tables (and associated address translation techniques)


A

B

C

D

A

B

C

D

Segment allocation

Logical Process Logical Process

Page-Frame allocation

External hole

External hole

Internal hole

RAM RAM


5 State ModelThe minimum project requirement is to implement a

5-state process execution modelThis model may be extended in various ways (some

are suggested further on in these slides, in the textbook and in lectures)Such extensions are good candidates for additional

marks, and will lead to deeper understanding if undertaken


Virtual Machine Architecture Since an actual computer architecture is too complicated for the purposes of this

project, each group will simulate a model of a simplified computer – essentially a Virtual Machine.

The characteristics of this machine will vary, according to the approach used, but should include consideration of the following points.

CPU PC, SP, general purpose registers (as required)

RAM Separate the user memory from that used by the O/S

Bus Although this is important in real systems, it can be safely ignored in this project,

unless students wish to explore the notion of cache memories and buses with different speeds. Bus speeds are constant factors that may be included with other timing factors.

I/O channels Each device should be dealt with as independent entities, with a communications

interface located at a specific memory address


Virtual Machine Architecture Clock

In actual computers there is a master clock used to synchronize and time other clocks and timings

In this project time must be simulated carefully It is recommended to use a global (ie public) variable for the clock time so that

logical operations (whether CPU instructions, I/O or other communications or logic) can all update the time according to their specifications

Instructions It is not necessary to design an elaborate instruction set – it is sufficient to assume

two categories of instructions CPU instructions are executed without interruption (non-preemptive), unless they

throw their own exceptions. Further, CPU (including bus transfers) instructions have constant timing and are non-preemptive (atomic)

I/O transactions also have constant timings (albeit considerably longer than CPU)


Virtual Machine Architecture Devices

Each device must be registered within the O/S – this is done using tables with recorded values, including timing, buffering and other data, depending on teh device

There is a standard wait cycle per device for I/O There is a standard buffer size requirement per device

Privileged architecture The operating system itself may require certain specialized devices and virtual

hardware that must also be managed. These might include, among others, Specialized registers Timings of software modules (eg. schedulers, resource managers, allocators, recovery,

exception handlers, queue managers, etc)


ResourcesAs a resource Time is dealt with through scheduling, using the

system Clock. However, resources that require allocation and management of usage typically refer to hardware devices Disks, tapes, CD/DVD, keyboards/mice, monitors Each with their own characteristics, timings and memory buffering needs

RAM Allocations of memory blocks to processes and device transactions must

be managed Recovery of memory allocations must be managed for re-use The memory allocation model to be used is the page-frame model.

I/O devices Several types of devices and device characteristics must be defined for

this project – keep it simple!


New StateWhen a program (aka job) is submitted, the O/S utility program

called the Loader (aka Loader/Linker) strips the header off the program file and then proceeds to analyze it for immediate rejection based on exceeding total resource availability for the requests being made.

If the job can be allocated sufficient resources, in principle, then a PCB is created for the job and initialized in all relevant fields, and finally added to the New State Queue.

The list (aka gang) of jobs is gathered until such time as the Long Term Scheduler module is executed on the job list.


New StateProgram header protocol describes the structure and semantics of

the resources requested by a program. The header is a dynamic data structure that can be simplified considerably for this project.

Header protocol:Header sizeProcess sizeProcess stack sizeBurst length (total runtime for process)Number of devices requestedList of each device requestedAny additional fields required


New StateEach of these items can be simply

represented by an <unsigned int> data type (assumed to be 32 bits)The size of the data structure is then N+4

words (of 32 bits each word)Note that the Burst length is generally not

known in advance, but must be provided in this project using simulation techniques, so as to support the SJF scheduling algorithm.

Additional fields and data may be supplied in order to meet the needs of particular extensions to the project goals.

The header information is used as input to the job allocation method to determine other O/S assigned values needed for the job’s PCB (eg. process id #, state data)

Header protocol:•Header size•Process size•Process stack size•Burst length (total runtime for process)•Number of devices requested•List of each device requested•Any additional fields required

PID

State data #1

State data #2

.....

State data #N

PCB


Long Term SchedulingLong term scheduling is performed on the processes in the New

queue(s)The PCB’s within queue(s) may have to be ordered (eg SJF), or left

intact (eg FCFS), or modified to the queue structure (eg RR).A multi-level queuing structure will be needed in this project.Only after the schedule has been determined is the scheduler

process itself interrupted and the PCB’s are then moved from the New queue(s) to the Ready queues. This is one area where it is possible to increase understanding and also

marks value by increasing the number of O/S process states – here one can include a New-Suspend state for a job that will not be scheduled for the Ready state for a lengthy time period – such jobs may utilize Virtual Memory (ie. disk storage).


Ready StateThe Ready state is managed using multi-level queues (of

PCB’s) used for Foreground and Background processes.

The amount of time provided to each queue must be proportioned with the objective being to keep the CPU busy and all processes moving towards termination

Each queue may have a different scheduling algorithmForeground jobs – RR (with FCFS)Background jobs – FCFS nonpreemptive, FCFS preemptive, SJFPriority should be considered also


Ready StateEach job entering a Ready queue must have RAM and

resources allocated according to its stated needs Thus, the total of all such allocations must not exceed the total available

resources In order to make room for a process to enter a Ready queue it may be

necessary to force another process to vacate the queue (become Suspended to Virtual Memory)

Each process in a Ready queue must be ready to execute on a context switch to the Running state This implies that all O/S tables must be updated and ready to apply to

Address translation Device channel allocation Kernel thread allocation All other management tables and lists


Short Term SchedulingShort term scheduling is executed frequently to ensure that CPU

usage is as intensive as possible. For processes in the Ready queues, this means moving queue positions to maximize opportunities for process execution

Various algorithms apply, depending on the queue FCFS RR (with FCFS) SJF – preemptive Interrupts must be accounted for in some methods

This scheduling also takes time that must be accounted for in the simulation.


Context Switching & DispatcherChanging context

requires PCB data exchanges in the virtual CPU

Updates to timings should be dealt with

This issue is connected to the design of the virtual architecture

PID

State data #1

State data #2

.....

State data #N

PCB 1

PID

State data #1

State data #2

.....

State data #N

PCB 2

CPUregisters

1 – Save context

2 – Load context


Running StateProcess execution must be simulated – no actual instructions will be

executed !There are several issues that must be accounted for

Processing timing Each process is ‘executed’ in a time quantum specified for each

scheduling algorithm and process type Total cpu timing

# of instructions x unit_cputime I/O interrupt timing

Total of all I/O interrupt times within the occurring quantum (note that there may be more than one)


Running StateException Handling

Various instructions may cause different types of runtime exceptions that may be simulated

Determine the exceptions to be simulated Examples: divide_by_zero, addressing, time allocation

exceeded (infinite loop problem) and others – keep it simple! Develop a random number based approach to predicting when

exceptions occur during Running state If an exception is ‘predicted’ then throw the exception handling

interrupt routine, and move the process immediately to the Termination state for resource recovery


Waiting StateWhen I/O interrupts occur the process that invokes them may or may

not require waiting for a response Output operations may be handled independently by microprocessors

(not the CPU) and CPU processing may continue. However, some attention should be paid to the time it takes for output operations to clear buffers, since subsequent output operations may create problems if overwriting of buffers occurs before all data has been outputted.

Input operations require suspending CPU instruction processing until a response is returned, along with any data in buffers

Short term scheduling may be adapted to permit processes with shorter time (than the quantum) interrupts to return to the Running state more quickly by using Priority scheduling in the Ready state


Waiting State Devices should have associated queues. This leads to straightforward

management for each device. Note that some devices may demand certain kinds of scheduling Printers should use FCFS Disks may use various schemes

Buffering should be considered in terms of its impact on timing considerations for I/O, allocation of memory to processes, implementation issues (in simulation) for swapping processes in and out of Virtual Memory, and any other matters

Timings will be important in scheduling algorithms and these are provided for each device in a device table

Interrupts may be implemented in various ways using simulation. Critical sections may be assumed for I/O transactions (but with careful thought about implications).


Medium Term SchedulingThe purpose of medium term scheduling is to get processes back

into the Ready state as efficiently as possible. The Waiting state uses multi-device queues feeding into a multi-level

queue system in the Ready state It is necessary to use state information stored in the PCBs

For additional realism (and design complexity) it should be noted that some Wait states may be so long (perhaps due to very low priority) that the process is better dealt with by moving it to Virtual Memory, thereby giving other processes more opportunity to progress This gives rise to Suspend/Blocked-Waiting state


Termination/Exit StateOn completion of a process it is moved to the Termination

state queue – there is no need to distinguish between these processes.

A scheduled Recovery process is run every so often and reclaimed resources are noted by updating resource tables to reflect the availability of those resources.Each process PCB is then deallocated – this also implies that a

previously used PID may be reused (although rarely is this required)


SynchronizationWhenever two or more processes attempt to access the

same resource at the same time conflicts may arise – for example,Writing to the same RAM locationReading or writing to the same file location

Process synchronization techniques can be usedMutual exclusion using semaphoresReaders-Writers problem Scheduling may also solve certain problems


Resource ManagementWe began by discussing the relationship between process needs

and the underlying architecture and resources available At job submission it is necessary to determine if a job’s needs can be

fulfilled – if not, it is rejected

The Banker’s algorithm deals with the allocation of resources to processes – it is a complex strategy that deals with: Resource allocation Deadlock detection Deadlock avoidance Raises the issue of deadlock recovery (which can be difficult, but may be

ignored usually)


Simulation ReportingThere are many tables that reflect the progress of processes and

resource management in your O/S simulation. These may be exploited to produce reports and provide test results. Scheduling Resources used (at each time step, or over time)

Design reports so they are simple and straightforward to understand May be sent to files for examination using an editor May be sent to screen using a simple menu system Graphs are very nice to show comparisons of results (especially

comparing scheduling algorithms)


Summary CommentsA fundamental conceptual model was presented

discussing the following (among other topics)ProcessArchitecture and Resources5-State ModelQueueing ModelSchedulingSynchronizationResource ManagementReporting

The primary benefit of this document is intended when it is used for extension and refinement of project goals and progress by each group.


Summary CommentsThis is a challenge project, but deeper consideration

will lead to much greater understanding and appreciation for the topic of operating systems, as well as knowledge concerning the systems you will use in the future.

Good luck and good programming !

Dr. Bob Kent, 2010


03-60-330-01 winter 2010 dr. robert d. kent last updated: wednesday, feb. 3, 2010 copyright ©...

Documents

stack space

processesa program

instruction space

total code space

course project

stack management

storage space

io buffer