Download on Operating Systems

More on Operating
Systems
Continuation of Introduction
Copyright © 2005 - Curt Hill
Multiprocessing
• Using multiple hardware processors to
increase executable speed
• Most mainframe and minicomputers have
multiple processors
– Usually have one CPU
– One or more I/O processors
– Usually we think of multiple independent
CPUs though in this context
• The main sticking point here is processor
communication
• Suppose that I have two CPUs that share
memory
– Somehow we need to guarantee no
concurrency errors
Copyright © 2005 - Curt Hill
Resource Allocation
• Single process OS
• The machine is divided between the
application and the system
• When the system is running it knows
that the application is suspended
waiting for it to finish
• Very easy - if it wants it and we have
it, it gets it
Copyright © 2005 - Curt Hill
Resource Allocation
• Multiple process - much more
complicated, but gives greater abilities to
the designer and user
• The strategy is then to give a process to
each thing that needs management
• The process would be given control,
check if action needs to be taken, if not
go back to sleep, if so do it and then go to
sleep
• The sleep command is basically just put
yourself back on the dispatchers list
Copyright © 2005 - Curt Hill
Processor management
and Process control
• Every program becomes a process
but not every process is a program
• Every process has some
characteristics
• A status: running, ready, blocked
– Blocked
• Some event must occur to allow
continuation
• Typical things include waiting for I/O or
other service to be satisfied
Copyright © 2005 - Curt Hill
Other process characteristics:
• Memory that it can access, both code and
data
– One program may have several processes,
which share the programs code and data
• Files and devices of the process
– This allocation may be to either the program
or the process
• Accounting information
– The process and the program are initiated by
some account
– Various chargeable resources are consumed
by it
• Priority and privileges
Copyright © 2005 - Curt Hill
Scheduling
•
•
•
•
Three types
Non pre-emptive
Permissive
Pre-emptive
Copyright © 2005 - Curt Hill
Non Pre-emptive Scheduling
• The process gives up the CPU when
it has no further use for it
– Done
– Waiting for a event to occur
• Any interrupts that occur always
return to the current process
• This is the form most versions of
DOS used
Copyright © 2005 - Curt Hill
Permissive Scheduling
• Allow the process to keep the CPU
until one of two things occur:
• They are done or waiting for an
event
– Similar to non pre-emptive
• They make any system call
• There is the notion of any interrupt
not necessarily returning to the
active process
• This is the form used by Window 3
and previous
Copyright © 2005 - Curt Hill
Pre-emptive Scheduling
• A time slice (clock timer interrupt)
occurs
– The process is put on the ready queue
and another started
– There is no dependence on the process
being well behaved
• This is used by most higher level
OSs such as UNIX, Windows 95,
Window NT and OS/2
Copyright © 2005 - Curt Hill
Dispatching
• Suppose a process terminates or moves
from running to blocked state
• A very important part of the OS is the
dispatcher
• This finds the new task to run or resume
• Which process gets CPU next?
• There are a number of algorithms to
determine who gets the next shot
• First come first served
• Shortest time remaining
Copyright © 2005 - Curt Hill
Task selection criteria
• Priority
– Some processes are more important so we
give them more shots
• How did the process give up the CPU?
– It may be better to favor those processes that
were blocked by service requests over those
that were time sliced
• A process that does a function call to the
supervisor allows something else to be
scheduled
– Every service request allows other processes
to continue, but there is one specifically for
allowing other tasks, that does no service
except run the dispatcher
Copyright © 2005 - Curt Hill
Memory management
• The goals of memory management
include:
• Utilize the CPU well by allowing as
many processes as possible to be
active
• Allow flexibility of memory usage by
programs
• Protect processes from each other,
so that no process can examine or
alter another process’s memory
Copyright © 2005 - Curt Hill
Memory map
• Starting at low memory, the usual
memory map has
• Nucleus or kernel
– Resident routines
– The service layer may be here or in
transients depending on its need
• Application
• Free space
• Transients (if needed)
Copyright © 2005 - Curt Hill
Memory utilization
• Once the nucleus size is established
• All that is needed is to load
applications at the right address
– By a relocating loader
• The command interpreter could load
at the same place as the
applications
Copyright © 2005 - Curt Hill
Partitions
• The next step is to partition the application area
and free space into fixed size pieces, called
partitions
– It is possible to collapse two adjacent partitions into
one if the program requires
– Fragmentation occurs here because programs are not
the exact sizes that the partitions have
• The next step is to make the partitions variable
sized
– This can allow memory to be fragmented, but the
fragmentation is short lived since when the thing above
finishes the two free spaces become one
• To get much better requires virtual memory
Copyright © 2005 - Curt Hill
Protection
• There has to be some mechanism in
a multitasking system that each
program can only access its own
memory and not the memory of
others
Copyright © 2005 - Curt Hill
System 360 Protection
• The 360 had a protection key
• Each user got a key 0-15
• You couldn’t change your key, nor did you even
know it before hand
• The PSW had the key in it
• The system used key 0, which gave it the ability
to access any memory
• Each 1K (or so) block of memory had its own key
• Any access or change of a block of memory by a
PSW with any key but the right one or zero
caused a protection fault and the program was
aborted
– These were usually caused by invalid instructions, wild
subscipts, bad pointers and the like
Copyright © 2005 - Curt Hill
An aside about queues
• Operating systems have a plethora of
queues, some of which should be
considered
• Virtually every resource has a queue of
demands on that resource
• The resource producer gets the request,
removing the item from the queue
– They usually put it back on another queue
• The processing of the request is usually
not instantaneous, but rather taking time,
so it may be in a holding state during
process
Copyright © 2005 - Curt Hill
Queues present
• Print queue
– Based upon form, kind of printer, location of
printer etc
• Processes
– Ready to run but waiting for a processor ready status
– There also exists a group of processes that
are waiting for some service or
communication - blocked status
– There also exists a group of processes that
are currently running - running status
– The latter two are not strictly speaking
queues, since it is not usually the first one in
line that exits first
Copyright © 2005 - Curt Hill
More queues
• Disk drive requests
– Each read and write becomes a separate
request for a particular drive and or channel
– In a single processing system this is not
needed since we never generate a second
until the first is done, but in multitasking we
may generate many such requests
– Each device that can be shared has a similar
queue to that of the above
• Jobs waiting to run
– This queue may be partitioned according to
classes of resources needed
• There are others as well
Copyright © 2005 - Curt Hill