--------------------------------------------------------------------------------

- ANSWERS TO PROBLEMS FROM CHAPTERS 8-14 -

--------------------------------------------------------------------------------
8.2 Is it possible to have a deadlock involving only one process? Explain your
answer.
Answer:
Recall that there are four necessary conditions for deadlock.
Number 4 is circular-wait. Deadlock with one process is not possible, because it
is not possible to have circular wait with only one process, thus failing a
necessary condition. There is no second process to form a circle with the first
one. For the same reason, it is not possible to have a deadlock involving only
one resource. This follows directly from the hold-and-wait condition.
--------------------------------------------------------------------------------
8.3 Consider the traffic deadlock depicted in the Figure 8.8.
A. Show that the four necessary conditions for deadlock indeed hold in this
example.
B. State a simple rule that will avoid deadlocks in this system.
Answer:
A. The four necessary conditions for deadlock hold in this example for the
following reasons
(i) Mutual Exclusion : Each of the vehicles present in the streets hold a
non-sharable resource: the part of the road they occupy, which they cannot share
with the other vehicles.
(ii) Hold and Wait : Each of the vehicles hold the space resource they
occupy and are waiting the space in front of them to be freed by other waiting
vehicles.
(iii) No Preemption : There is no possibility of preemption as none of the
vehicles can give up their resource. In this situation preemption would have to
take the form of a vehicle pulling into a parking lot, or a crane reaching down
and lifting a vehicle off the road.
(iv) Circular Wait : Circular wait is present because each vehicle is waiting
for the space in front of it, and some vehicles occupy spaces where two vehicles
wait on them. It is thus possible to trace a cycle of waiting cars. This is the
weakest assertion in the set, though, and is clearly untrue out at the edges
somewhere, since some car can clearly move someplace in the city.If you have
ever experienced grid-lock, though you know that this is small comfort, and tht
a rule to avoid even "local" deadlock is extremely desirable.
B. The simple rule that could be used to avoid traffic deadlocks in such a
system is that intersections should always remain clear as lights change. In
this way, the resource of space in the intersection is freed for use at
periodic intervals (light changes).
--------------------------------------------------------------------------------
8.10 Consider a computer system that runs 5,000 jobs per month with no
deadlock prevention or deadlock avoidance scheme. Deadlocks occur about twice
per month, and the operator must terminate and rerun about 10 jobs per deadlock.
Each job is worth about $2 (in CPU time) , and the jobs terminated tend to be
about halfâ done when they are aborted. A systems programmer has estimated that
a deadlockâ avoidance algorithm(like the Banker's algorithm ) could be
installed in the system with an increase in the average execution time per job
of about 10 percent. Since the machine currently has 30-percent idle time, all
5000 jobs per month could still be run, although turnaround time would increase
by about 20 percent on an average.
A. What are the arguments for installing the deadlock-avoidance algorithm?
B. What are the arguments against installing the deadlock-avoidance algorithm?
Answer:
A. The arguments in favour of installing the deadlock-avoidance
algorithm are : Avoids deadlocks and the costs of reruns. Avoids waste of
resources as the reruns require duplicate use of resources and time to run the
aborted processes all over again Increases useful utilization of the resources
as the systemâ s idle-time is reduced.
B. The arguments against installing the deadlock avoidance algorithm are :
Increases total execution time for processes. Increases the total cost as the
total execution time of processes increases by 10%. The processes take more time
to complete due to an increase in the turnaround time by 20 %. It introduces an
overhead on the execution of every processDeciding between the arguments in
favor and against deadlock control requires an examination of the costs
involved. In other words, it depends on the details of the situation.The problem
states that the computing load represents about $10K per month in computing
time, and that about 20 jobs having used $1 each in CPU time are terminated per
month (this information is easily derived fromt he facts stated in the problem).
That means that not controlling deadlock costs about $20 per month. The problem
also states that controlling deadlock introduces overhad costing about 10% on
every job, or about $500. The proposal to control deadlock thus proposes to
spend about $500 (overhead) to save about $20 (deadlock loss).
--------------------------------------------------------------------------------
9.1 Name two differences between logical and physical addresses.
Answer:
Logical address is an address seen by the CPU while a physical
address is seen by the memory. A physical address is limited to the amount
of installed memory while a logical address is limited by the address size of
the processor.
--------------------------------------------------------------------------------
9.2 Explain the difference between internal and external fragmentation.
Answer: Internal Fragmentation is the area in a region or a page that is not
used by the job occupying that region or page. This space is unavailable for use
by the system until that job is finished and the page or region is released.
External fragmentation is the area or region that is not used because it is
free.
--------------------------------------------------------------------------------
9.3 Descibe the following allocation algorithms:
(A) First-fit: search the list of available memory and allocate the first block
that is big enough.
(B) Best-fit: search the entire list of available memory and allocate the
smallest block that is big enough.
(C) Worst-fit: search the entire list of available memory and allocate the
largest block.
--------------------------------------------------------------------------------
9.5 Given memory partitions of 100K, 500K, 200K, 300K, and 600K (in
order), how would each of the First-fit, Best-fit, and Worst-fit
algorithms place processes of 212K, 417K, 112K, and 426K (in
order)? Which algorithm makes the most efficient use of memory?
Answer:
a. First-fit:
212K is put in 500K partition
417K is put in 600K partition
112K is put in 288K partition (new partition 288K = 500K - 212K)
426K must wait
b. Best-fit:
212K is put in 300K partition
417K is put in 500K partition
112K is put in 200K partition
426K is put in 600K partition
c. Worst-fit:
 212K is put in 600K partition
417K is put in 500K partition
112K is put in 388K partition
426K must wait
In this example, Best-fit turns out to be the best.
--------------------------------------------------------------------------------
9.8 Consider a logical address space of eight pages of 1024 words each,
mapped onto a physical memory of 32 frames.
A. How many bits are there in the logical address?
B. How many bits are there in the physical address?
Answer:
A. Logical address: 13 bits
B. Physical address: 15 bits
--------------------------------------------------------------------------------
9.16 Consider the following segment table:
Segment Base Length
0 219 600
1 2300 14
2 90 100
3 1327 580
4 1952 96
What are the physical addresses for the following logical addresses?
a. 0,430 b. 1,10 c. 2,500 d. 3,400 e. 4,112
Answer:
A. 219 + 430 = 649
B. 2300 + 10 = 2310
C. illegal reference, trap to operating system
D. 1327 + 400 = 1727
E. illegal reference, trap to operating system
--------------------------------------------------------------------------------
10.2 Assume that you have a page-reference string for a process with m
frames (initially all empty). The page-reference string has length p; n distinct
page numbers occur in it. Answer these questions for any page-replacement
algorithms:
A. What is a lower bound on the number of page faults?
B. What is an upper bound on the number of page faults?
Answer:
A. N, because a distinct page numbers always generates a page fault, even if
two difference pages refer to the same physical page frame.
B. P, if we reference pages P times, we will generate at most P page faults.
--------------------------------------------------------------------------------
Problem 10.2: Assume that you have a page-reference string for a process with
m frames (initially all empty). The page-reference string has length p; n
distinct page numbers occur in it. Answer these questions for any page
replacement algorithm:
A. What is a lower bound on the number of page faults?
B. What is an upper bound on the number of page faults?
Answer:
A. Lower Bound: n. The reference string indicates that the program actually
references n distinct pages, and the best that any page replacement algorithm
can do is make the first page fault for a page the last.
B. Upper Bound: p. The worst possible situation is one where the working set
is so small, and the page replacement algorithm so stupid, that every reference
to a new page in the reference string is a page fault.
--------------------------------------------------------------------------------
10.4 Which
of the following programming techniques and structures are "good" for a demand-
paged environment ? Which are "not good"? Explain your answers.
a. Stack
b. Hashed symbol table
c. Sequential search
d. Binary search
e. Pure code
f. Vector operations
g. Indirection
Answer:
a. Stack--good.
b. Hashed symbol table--not good.
c. Sequential search--good.
d. Binary search--not good.
e. Pure code--good.
f. Vector operations--good.
g. Indirection--not good.
--------------------------------------------------------------------------------
10.9 Consider a demand-paging system with the following time-measured
utilizations:
CPU utilization 20%
Paging disk 97.7%
Other I/O devices 5%
--------------------------------------------------------------------------------
11.5 What are the advantages and disadvantages of recording the name
of the creating pro- gram with the file's attributes (as is done
in the Macintosh Operating System)?
Answer: By recording the name of the creating program, the
operating system is able to implement features (such as automatic
program invocation when the file is accessed) based on this
information. It does add overhead in the operating system and
require space in the file descriptor, however.
--------------------------------------------------------------------------------
11.5 What are the advantages and disadvantages of recording the name of
the program that creates a file with the file's attributes (as is done in the
Macintosh operating system)?
Answer:
Advantages: A file tagged with a program name
indirectly points to the default program to open/execute the file. Firstly, this
makes file dependency on application programs very explicit. This visibility is
useful (more than that in having extensions in DOS and Windows) to the user in
determining the type associated with the file. Furthermore, this is more
risk-free in determining the program to open a file. A weird program cannot
accidentally corrupt (unless forced by the user) the internal format of a file
in trying to open it since here each file is named with the only program(s) that
has/have access to it. Thus this makes the system more secure.Disadvantages:
This strategy gives birth to long file names. Systems which deal with large
number of files waste a considerable amount of space in storing the names of
these files. Moreover, this reduces portability of the file. If a file is moved
from one environment to another, then it would become useless if that particular
program is unavailable to open it unless the file name is modified. A subtle
error creeping inside the file-name may also render it completely paralyzed.
Also, some files are used by multiple applications, so the one-to-one mapping
with the embedded filename is much less useful in reality.
--------------------------------------------------------------------------------
11.7 Explain the
purpose of the open and close operations.Answer: The open operation informs
the system that the named file is about to become active. The close operation
informs the system that the named file is no longer in active use by the user
who issued the close operation.
--------------------------------------------------------------------------------
11.9 Give an example of an application in
which data in a file should be accessed in the following order:
A. Sequentially: A movie player that plays a movie file sequentially.
B. Randomly: A movie player that allows user to start playing movie at random
locations of the file.
--------------------------------------------------------------------------------
11.13 Researchers have suggested that, instead of having an access list
associated with each file(specifying which users can access the file, and how),
we should have a user control listassociated with each user (specifying which
files a user can access, and how). Discuss therelative merits of these two
schemes.
Answer:
- File control list. Since the access control information is concentrated in
one single place, it is easier to change access control information and
this requires less space.
- User control list. This requires less overhead when opening a file.
--------------------------------------------------------------------------------
12.2 Consider a system where free space is kept in a free-space list.
A. Suppose that the pointer to the free-space list is lost. Can the
system reconstruct the free-space list? Explain your answer.
B. Suggest a scheme to ensure that the pointer is never lost as
result of memory failure.
Answer:
A. In order to reconstruct the free list, it would be necessary to
perform "garbage collection." This would entail searching the entire
directory structure to determine which pages are already allocated to
jobs. Those remaining unallocated pages could be relinked as the
free-space list.
B. The free-space list pointer could be stored on the disk, perhaps in
several places.
--------------------------------------------------------------------------------
12.4 Why must the bit map for file allocation be kept on mass storage, rather
than in main memory?
Answer:
In case of system crash (memory failure) the free-space list would not
be lost as it would be if the bit map had been stored in main memory.
--------------------------------------------------------------------------------
12.5 Consider a system that supports the strategies of contiguous, linked, and
indexed allo-cation. What criteria should be used in deciding which strategy is
best utilized for a particular file?
Answer:
Contiguous -- if file is usually accessed sequentially, if file is
relatively small. Linked -- if file is large and usually accessed
sequentially. Indexed -- if file is large and usually accessed
randomly.
--------------------------------------------------------------------------------
13.1 State three advantages of placing functionality in a device controller,
rather than in the kernel. State three disadvantages.
Answer:
Three advantages: Bugs are less likely to cause an operating system
crash. Performance can be improved by utilizing dedicated hardware and
hard-coded algo-rithms. The kernel is simplified by moving algorithms out of it.
Three disadvantages: Bugs are harder to fix - a new firmware version or
new hardware is needed. Improving algorithms likewise require a hardware updatei
rather than just kernel or device driver update. Embedded algorithms could
conflict with application's use of the device, causing de-creased performance.
--------------------------------------------------------------------------------
13.2 Consider the following I/O scenarios on a single-user PC.
A. A mouse used with a graphical user interface
B. A tape drive on a multitasking operating system (assume no device
preallocation is available)
C. A disk drive containing user files
D. A graphics card with direct bus connection, accessible through
memory-mapped I/O
For each of these I/O scenarios, would you design the operating system
to use buffering, spooling, caching, or a combination? Would you use
polled I/O, or interrupt-driven I/O? Give reasons for your choices.
Answer:
A. A mouse used with a graphical user interface Buffering may be
needed to record mouse movement during times when higher- priority
operations are taking place. Spooling and caching are
inappropriate. Inter- rupt driven I/O is most appropriate.
B. A tape drive on a multitasking operating system (assume no device
preallocation is available) Buffering may be needed to manage
throughput difference between the tape drive and the source or
destination of the I/O, Caching can be used to hold copies of data
that resides on the tape, for faster access. Spooling could be used to
stage data to the device when multiple users desire to read from or
write to it. Interrupt driven I/O is likely to allow the best
performance.
C. A disk drive containing user files. Buffering can be used to hold
data while in transit from user space to the disk, and visa
versa. Caching can be used to hold disk-resident data for improved
perfor- mance. Spooling is not necessary because disks are
shared-access devices. Interrupt- driven I/O is best for devices such
as disks that transfer data at slow rates.
D. A graphics card with direct bus connection, accessible through
memory-mapped I/O Buffering may be needed to control multiple access
and for performance (double- buffering can be used to hold the next
screen image while displaying the current one). Caching and spooling
are not necessary due to the fast and shared-access natures of the
device. Polling and interrupts are only useful for input and for I/O
completion detection, neither of which is needed for a memory-mapped
device.
--------------------------------------------------------------------------------
13.5 Why might a system use interrupt-driven I/O to manage a single
serial port, but polling I/O to manage a front-end processor, such as
a terminal concentrator?
Answer:
 Polling can be more efficient than interrupt-driven I/O. This
is the case when the I/O is frequent and of short duration. Even
though a single serial port will perform I/O relatively infrequently
and should thus use interrupts, a collection of serial ports such as
those in a terminal concentrator can produce a lot of short I/O
operations, and interrupting for each one could create a heavy load on
the system. A well-timed polling loop could alleviate that load
without wasting many resources through looping with no I/O needed.
--------------------------------------------------------------------------------
14.1 None of the disk-scheduling disciplines, except FCFS, is truly fair
(starvation may occur).
A. Explain why this assertion is true.
B. Describe a way to modify algorithms such as SCAN to ensure fairness.
C. Explain why fairness is an important goal in a time-sharing system.
D. Give three or more examples of circumstances in which it is important
that the op- erating system be unfair in serving I/O requests.
Answer:
A. New requests for the track over which the head currently resides
can theoretically arrive as quickly as these requests are being
serviced.
B. All requests older than some predetermined age could be "forced"
to the top of the queue, and an associated bit for each could be
set to indicate that no new request could be moved ahead of
these requests. For SSTF, the rest of the queue would have to be
reorganized with respect to the last of these "old" requests.
C. To prevent unusually long response times.
D. Paging and swapping should take priority over user requests. It
may be desirable for other kernel-initiated I/O, such as the
writing of file system metadata, to take precedence over user
I/O. If the kernel supports real-time process priorities, the
I/O requests of those processes should be favored.
--------------------------------------------------------------------------------
14.2 Suppose that a disk drive has 5000 cylinders, numbered 0 to
4999. The drive is currently serving a request at cylinder 143,
and the previous request was at cylinder 125. The queue of
pending requests, in FIFO order, is
86, 1470, 913, 1774, 948, 1509, 1022, 1750, 130
Starting from the current head position, what is the total
distance (in cylinders) that the disk arm moves to satisfy all the
pending requests, for each of the following disk- scheduling
algorithms?
A. FCFS
B. SSTF
C. SCAN
D. LOOK
E. C-SCAN
F. C-LOOK
Answer:
A. The FCFS schedule is 143, 86, 1470, 913, 1774, 948, 1509,
1022, 1750, 130. The total seek distance is 7081.
B. The SSTF schedule is 143, 130, 86, 913, 948, 1022, 1470,
1509, 1750, 1774. The total seek distance is 1745.
C. The SCAN schedule is 143, 913, 948, 1022, 1470, 1509, 1750,
1774, 4999, 130, 86. The total seek distance is 9769.
D. The LOOK schedule is 143, 913, 948, 1022, 1470, 1509, 1750,
1774, 130, 86. The total seek distance is 3319.
 E. The C-SCAN schedule is 143, 913, 948, 1022, 1470, 1509,
1750, 1774, 4999, 0, 86, 130. The total seek distance is
9985.
F. The C-LOOK schedule is 143, 913, 948, 1022, 1470, 1509,
1750, 1774, 86, 130. The total seek distance is 3363.
--------------------------------------------------------------------------------
14.7 Compare the performance of C-SCAN and SCAN scheduling, assuming a uniform
distributionof requests. Consider the average response time (the time between
the arrival of arequest and the completion of that request s service), the
variation in response time, andthe effective bandwidth. How does performance
depend on the relative sizes of seek timeand rotational latency?
Answer:
There is no simple analytical argument to answer the first part of this
question. It wouldmake a good small simulation experiment for the students. The
answer can be found inFigure 2 ofWorthington et al. [1994]. (Worthington et al.
studied the LOOK algorithm, butsimilar results obtain for SCAN. Figure 2 in
Worthington et al. shows that C-LOOK has anaverage response time just a few
percent higher than LOOK but that C-LOOK has a significantlylower variance in
response time for medium and heavy workloads. The intuitivereason for the
difference in variance is that LOOK (and SCAN) tend to favor requests nearthe
middle cylinders, whereas the C-versions do not have this imbalance. The
intuitive reasonfor the slower response time of C-LOOK is the  circular seek
from one end of the disk to the farthestrequest at the other end. This seek
satisfies no requests. It only causes a small performancedegradation because the
square-root dependency of seek time on distance implies that a long seekisn t
terribly expensive by comparison with moderate length seeks.For the second part
of the question, we observe that these algorithms do not schedule to
improverotational latency; therefore, as seek times decrease relative to
rotational latency, the performancedifferences between the algorithms will
decrease.
--------------------------------------------------------------------------------
14.9 Explain why SSTF scheduling tends to favor the middle cylinders of a disk
over the innermost and outermost cylinders.
Answer:
The SSTF algorithm is biased toward the middle cylinders in much the same
way the SCAN algorithm is. Since, in the SSTF algorithm, the closest cylinder
is always chosen, then all middle cylinder references will serviced on the way
to the end of the disk. I present the book's answer to this question, even
though I think it is more muddled... just FYI:The center of the disk is the
location having the smallest average distance to all other tracks. Thus the
disk head tends to move away from the edges of the disk.Here is another way to
think of it. The current location of the head divides the cylinders into two
groups. If the head is not in the center of the disk and a new request arrives,
the new request is more likely to be in the group that includes the center of
the disk; thus, the head is more likely to move in that direction.
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
NOTES FROM CHAPTER 8 Deadlock
--------------------------------------------------------------------------------
A set of processes is in a deadlock state when every process in the set is waiti
ng for an event that can be caused only by another process in the set.
8.2.1 Necessary Conditions
A deadlock situation can arise if the following four conditions hold simultaneo
usly in a system:
1. Mutual exclusion: At least one resource must be held in a nonsharable mode;
that is, only one process at a time can use the resource. If another process re
quests that resource, the requesting process must be delayed until the resource
has been released.
2. Hold and wait: A process must be holding at least one resource and waitin
g to acquire additional resources that are currently being held by other process
es.
3. No preemption: Resources cannot be preempted; that is, a resource can be re
leased only voluntarily by the process holding it, after that process has comple
ted its task.
4. Circular wait: A set {Po,Pi,..., Pn} of waiting processes must exist such tha
t PO is waiting for a resource that is held by P\, P\ is waiting for a resourcet
hat is held by P2, ..., Pn-\ is waiting for a resource that is held by P,,, and
P,, is waiting for a resource that is held by PQ.
8.3 - Methods for Handling Deadlocks
Principally, we can deal with the deadlock problem in one of three ways:
- We can use a protocol to prevent or avoid deadlocks, ensuring that the system
will never enter a deadlock state.
- We can allow the system to enter a deadlock state, detect it, and recover.
- We can ignore the problem altogether and pretend that deadlocks never occur i
n the system.
To ensure that deadlocks never occur, the system can use either a deadlock-preve
ntion or a deadlock-avoidance scheme. Deadlock prevention is a set of methods fo
r ensuring that at least one of the necessary conditions (Section 8.2.1) cannot
hold. These methods prevent deadlocks by constraining how requests for resources
can be made.
Deadlock avoidance requires that the operating system be given in advance additi
onal information concerning which resources a process will request and use durin
g its lifetime. With this additional knowledge, we can decide for each request w
hether or not the process should wait. To decide whether the current request can
be satisfied or must be delayed, the system must consider the resources current
ly available, the resources currently allocated to each process, and the future
requests and releases of each process.
If a system does not employ either a deadlock-prevention or a deadlock-avoidance
algorithm, then a deadlock situation may occur. In this environment, the system
can provide an algorithm that examines the state of the system to determine whe
ther a deadlock has occurred and an algorithm to recover from the deadlock (if
a deadlock has indeed occurred).
Deadlock Prevention
As we noted in Section 8.2.1, for a deadlock to occur, each of the four necessar
y conditions must hold. By ensuring that at least one of these conditions cannot
hold, we can prevent the occurrence of a deadlock. We elaborate on this approac
h by examining each of the four necessary conditions separately.
8.4.1 Mutual Exclusion
In general, however, we cannot prevent deadlocks by denying the mutual-exclusion
condition, because some resources are intrinsically nonsha rable.
8.4.2 Hold and Wait
To ensure that the hold-and-wait condition never occurs in the system, we must g
uarantee that, whenever a process requests a resource, it does not hold any othe
r resources. One protocol that can be used requires each process to request and
be allocated all its resources before it begins execution. We can implement this
provision by requiring that system calls requesting resources for a process pre
cede all other system calls. An alternative protocol allows a process to reques
t resources only when it has none. A process may request some resources and use
them. Before it can request any additional resources, however, it must release a
ll the resources that it is currently allocated. Both these protocols have two
main disadvantages. First, resource utilization may be low, since resources may
be allocated but unused for a long period. In the example given, for instance,
we can release the tape drive and disk file, and then again request the disk fil
e and printer, only if we can be sure that our data will remain on the disk file
. If we cannot be assured that they will, then we must request all resources at
the beginning for both protocols. Second, starvation is possible. A process tha
t needs several popular resources may have to wait indefinitely, because at leas
t one of the resources that it needs is always allocated to some other process.
8.4.3 No Preemption
The third necessary condition is that there be no preemption of resources that h
ave already been allocated. To ensure that this condition does not hold, we can
use the following protocol. If a process is holding some resources and requests
another resource that cannot be immediately allocated to it (that is, the proces
s must wait), then all resources currently being held are preempted. In other wo
rds, these resources are implicitly released. The preempted resources are added
to the list of resources for which the process is waiting. The process will be r
estarted only when it can regain its old resources, as well as the new ones that
it is requesting.
Alternatively, if a process requests some resources, we first check whether they
are available. If they are, we allocate them. If they are not, we check whether
they are allocated to some other process that is waiting for additional resourc
es. If so, we preempt the desired resources from the waiting process and allocat
e them to the requesting process. If the resources are neither available nor hel
d by a waiting process, the requesting process must wait. While it is waiting, s
ome of its resources may be preempted, but only if another process requests them
. A process can be restarted only when it is allocated the new resources it is r
equesting and recovers any resources that were preempted while it was waiting.
8.4.4 Circular Wait
The fourth and final condition for deadlocks is the circular-wait condition. One
way to ensure that this condition never holds is to impose a total ordering of
all resource types and to require that each process requests resources in anincr
easing order of enumeration.
8.5 Deadlock Avoidance
Deadlock-prevention algorithms, as discussed in Section 8.4, prevent deadlocks b
y restraining how requests can be made. The restraints ensure that at least one
of the necessary conditions for deadlock cannot occur and, hence, that deadlocks
cannot hold. Possible side effects of preventing deadlocks by this method, howe
ver, are low device utilization and reduced system throughput.
An alternative method for avoiding deadlocks is to require additional informatio
n about how resources are to be requested. For example, in a system with one tap
e drive and one printer, we might be told that process P will request first the
tape drive, and later the printer, before releasing both resources. Process Q, h
owever, will request first the printer and then the tape drive. With this knowle
dge of the complete sequence of requests and releases for each process, we can d
ecide for each request whether or not the process should wait in order to avoid
a possible future deadlock. Each request requires that in making this decision t
he system consider the resources currently available, the resources currently al
located to each process, and the future requests and releases of each process.
The various algorithms differ in the amount and type of information required. Th
e simplest and most useful model requires that each process declare the maximum
number of resources of each type that it may need. Given this a priori informati
on, it is possible to construct an algorithm that ensures that the system will n
ever enter a deadlocked state. Such an algorithm defines the deadlock-avoidance
approach. A deadlock-avoidance algorithm dynamically examines the resource-allo
cation state to ensure that a circular-wait condition can never exist.
8.6 Deadlock Detection
If a system does not employ either a deadlock-prevention or a deadlock-avoidance
algorithm, then a deadlock situation may occur. In this environment, the system
must provide:
- An algorithm that examines the state of the system to determine whether a dea
dlock has occurred
- An algorithm to recover from the deadlock
8.7 - Recovery from Deadlock
When a detection algorithm determines that a deadlock exists, several alternati
ves are available. One possibility is to inform the operator that a deadlock has
occurred and to let the operator deal with the deadlock manually. The other pos
sibility is to let the system recover from the deadlock automatically. There are
two options for breaking a deadlock. One is simply to abort one or more process
es to break the circular wait. The other is to preempt some resources from one o
r more of the deadlocked processes.
8.7.1 Process Termination
To eliminate deadlocks by aborting a process, we use one of two methods. In both
methods, the system reclaims all resources allocated to the terminated processe
s.
- Abort all deadlocked processes: This method clearly will break the deadlock
cycle, but at great expense; the deadlocked processes may have computed for a l
ong time, and the results of these partial computations must be discarded and pr
obably will have to be recomputed later.
- Abort one process at a time until the deadlock cycle is eliminated: This meth
od incurs considerable overhead, since, after each process is aborted, a deadloc
k-detection algorithm must be invoked to determine whether any processes are sti
ll deadlocked.
8.7.2 Resource Preemption
To eliminate deadlocks using resource preemption, we successively preempt some r
esources from processes and give these resources to other processes until the de
adlock cycle is broken.
If preemption is required to deal with deadlocks, then three issues need to be a
ddressed:
1. Selecting a victim: Which resources and which processes are to be preempte
d? As in process termination, we must determine the order of preemption to mini
mize cost. Cost factors may include such parameters as the number of resources a
deadlocked process is holding and the amount of time the process has thus far c
onsumed during its execution.
2. Rollback: If we preempt a resource from a process, what should be done with
that process? Clearly, it cannot continue with its normal execution; it is miss
ing some needed resource. We must roll back the process to some safe state and r
estart it from that state.
Since, in general, it is difficult to determine what a safe state is, the simple
st solution is a total rollback: Abort the process and then restart it. Although
it is more effective to roll back the process only as far as necessary to break
the deadlock, this method requires the system to keep more in formation about t
he state of all running processes.
3. Starvation: How do we ensure that starvation will not occur? That is, how can
we guarantee that resources will not always be preempted from the same process?
In a system where victim selection is based primarily on cost factors, it may h
appen that the same process is always picked as a victim. As a result, this proc
ess never completes its designated task, a starvation situation that needs to be
dealt with in any practical system. Clearly, we must ensure that a process can b
e picked as a victim only a (small) finite number of times. The most common solu
tion is to include the number of rollbacks in the cost factor.
--------------------------------------------------------------------------------
NOTES FROM CHAPTER 9 Memory Manegement
--------------------------------------------------------------------------------
Classically, the binding of instructions and data to memory addresses can be don
e at any step along the way:
- Compile time: If you know at compile time where the process will reside in m
emory, then absolute code can be generated. For example, if you know that a user
process will reside starting at location R, then the generated compiler code wi
ll start at that location and extend up from there. If, at some later time, the
starting location changes, then it will be necessary to recompile this code. The
MS-DOS .COM-format programs are bound at compile time.
- Load time: If it is not known at compile time where the process will reside i
n memory, then the compiler must generate relocatable code. In this case, final
binding is delayed until load time. If the starting address changes, we need onl
y reload the user code to incorporate this changed value.
- Execution time: If the process can be moved during its execution from one memo
ry segment to another, then binding must be delayed until run time. Special hard
ware must be available for this scheme to work, as will be discussed in Section
9.1.2. Most general-purpose operating systems use this method.
With dynamic linking, a stub is included in the image for each library-routine r
eference. The stub is a small piece of code that indicates how to locate the app
ropriate memory-resident library routine or how to load the library if the routi
ne is not already present. When the stub is executed, it checks to see whether t
he needed routine is already in memory. If not, the program loads the routine in
to memory.
9.1.5 Overlays
To enable a process to be larger than the amount of memory allocated to it, we c
an use overlays. The idea of overlays is to keep in memory only those instructio
ns and data that are needed at any given time. When other instructions are neede
d, they are loaded into space occupied previously by instructions that are no lo
nger needed.
The programmer, however, must design and program the overlay structure properly.
This task can be a major undertaking, requiring complete knowledge of the stru
cture of the program, its code, and its data structures. Because the program is,
by definition, large-small programs do not need to be overlaid- obtaining a suf
ficient understanding of the program may be difficult. For these reasons, the us
e of overlays is currently limited to microcomputer and other systems that have
limited amounts of physical memory and that lack hardware support for more adva
nced techniques.
9.2 - Swapping
A process must be in memory to be executed. A process, however, can be swapped t
emporarily out of memory to a backing store and then brought back into memory fo
r continued execution. For example, assume a multiprogramming environment with
a round-robin CPU-scheduling algorithm. When a quantum expires, the memory manag
er will start to swap out the process that just finished and to swap another pro
cess into the memory space that has been freed (Figure 9.4). In the meantime, th
e CPU scheduler will allocate a time slice to some other process in memory.
A variant of this swapping policy is used for priority-based scheduling algorith
ms. If a higher-priority process arrives and wants service, the memory manager c
an swap out the lower-priority process and then load and execute the higher-prio
rity process. When the higher-priority process finishes, the lower-priority proc
ess can be swapped back in and continued. This variant of swapping is sometimes
called roll out, roll in.
Normally, a process that is swapped out will be swapped back into the same memor
y space that it occupied previously. This restriction is dictated by the method
of address binding. If binding is done at assembly or load time, then the proces
s cannot be easily moved to a different location. If execution-time binding is b
eing used, however, then a process can be swapped into a different memory space,
because the physical addresses are computed during execution time.
Whenever the CPU scheduler decides to execute a process, it calls the dispatcher
. The dispatcher checks to see whether the next process in the queue is in memor
y. If it is not, and if there is no free memory region, the dispatcher swaps out
a process currently in memory and swaps in the desired process. It then reloads
registers and transfers control to the selected process.
The context-switch time in such a swapping system is fairly high. To get an idea
of the context-switch time, let us assume that the user process is of size 1 MB
and the backing store is a standard hard disk with a transfer rate of 5 MB per
second. The actual transfer of the 1-MB process to or from main memory takes
1000KB/5000KB per second = 1/5 second = 200 milliseconds.
Assuming that no seeks are necessary and an average latency of 8 milliseconds,t
he swap time is 208 milliseconds. Since we must both swap out and swap in, the t
otal swap time is then about 416 milliseconds.
9.3 - Contiguous-Memory Allocation
The main memory must accommodate both the operating system and the various user
processes. We therefore need to allocate the parts of the main memory in the mos
t efficient way possible. This section explains one common method, contiguous me
mory allocation.
The major factor affecting this decision is the location of the interrupt vector
. Since the interrupt vector is often in low memory, programmers usually place t
he operating system in low memory as well. Thus, in this text, we discuss only t
he situation where the operating system resides in low memory. The development o
f the other situation is similar. We usually want several user processes to res
ide in memory at the same time. We therefore need to consider how to allocate av
ailable memory to the processes that are in the input queue waiting to be brough
t into memory. In this contiguous-memory allocation, each process is contained i
n a single contiguous section of memory.
9.3.1 Memory Protection
Before discussing memory allocation further, we must discuss the issue of memory
protection-protecting the operating system from user processes and protecting u
ser processes from one another. We can provide this protection by using a reloca
tion register, as discussed in Section 9.1.2, with a limit register, as discusse
d in Section 2.5.3. The relocation register contains the value ofthe smallest ph
ysical address; the limit register contains the range of logical addresses (for
example, relocation = 100040 and limit = 74600). With relocation and limit regis
ters, each logical address must be less than the limit register; the MMU maps th
e logical address dynamically by adding the value in the relocati on register. T
his mapped address is sent to memory (Figure 9.5).
When the CPU scheduler selects a process for execution, the dispatcher loads the
relocation and limit registers with the correct values as part of the context s
witch. Because every address generated by the CPU is checked against these regis
ters, we can protect both the operating system and the other users' programs and
data from being modified by this running process.
For example, the operating system contains code and buffer space for device driv
ers. If a device driver (or other operating-system service) is not commonly used
, we do not want to keep the code and data in memory, as we might be able to use
that space for other purposes. Such code is sometimes called transient operati
ng-system code; it comes and goes as needed. Thus, using this code changes the s
ize of the operating system during program execution.
9.3.2 Memory Allocation
Now we are ready to turn to memory allocation. One of the simplest methods for m
emory allocation is to divide memory into several fixed-sized partitions. Each p
artition may contain exactly one process. Thus, the degree of multiprogramming
is bound by the number of partitions. In this multiple-partition method, when a
partition is free, a process is selected from the input queue and is loaded into
the free partition.
In the fixed-partition scheme, the operating system keeps a table indicating whi
ch parts of memory are available and which are occupied. Initially, all memory i
s available for user processes and is considered as one large block of available
memory, a hole. When a process arrives and needs memory, we search for a hole la
rge enough for this process. If we find one, we allocate only as much memory as
is needed, keeping the rest available to satisfy future requests.
This procedure is a particular instance of the general dynamic storage-allocatio
n problem, which concerns how to satisfy a request of size n from a list of free
holes. There are many solutions to this problem. The first-fit, best-fit, and w
orst-fit strategies are the ones most commonly used to select a free hole from t
he set of available holes. First fit: Allocate the first hole that is big enoug
h. Searching can start either at the beginning of the set of holes or where the
previous first-fit search ended. We can stop searching as soon as we find a free
hole that is large enough.
- Best fit: Allocate the smallest hole that is big enough. We must search the
entire list, unless the list is ordered by size. This strategy produces the sm
allest leftover hole.
- Worst jit: Allocate the largest hole. Again, we must search the entire list,
unless it is sorted by size. This strategy produces the largest leftover hole,
which may be more useful than the smaller leftover hole from a best-fit approach
.
Simulations have shown that both first fit and best fit are better than worst fi
t in terms of decreasing time and storage utilization. Neither first fit nor bes
t fit is clearly better than the other in terms of storage utilization, but firs
t fit is generally faster.
9.4 - Paging
Paging is a memory-management scheme that permits the physical-address space of
a process to be noncontiguous. Paging avoids the considerable problem of fittin
g memory chunks of varying sizes onto the backing store; most memory-management
schemes used before the introduction of paging suffered from this problem. The p
roblem arises because, when some code fragments or data residing in main memory
need to be swapped out, space must be found on the backing store. The backing st
ore also has the fragmentation problems discussed in connection with main memory
, except that access is much slower, so compaction is impossible. Because of its
advantages over earlier methods, paging in its various forms is commonly used i
n most operating systems.
9.4.1 Basic Method
The basic method for implementing paging involves breaking physical memory into
fixed-sized blocks called frames and breaking logical memory into blocks of the
same size called pages. When a process is to be executed, its pages are loaded i
nto any available memory frames from the backing store. The backing store is div
ided into fixed-sized blocks that are of the same size as the memory
frames. The hardware support for paging is illustrated in Figure 9.6. Every ad
dress gene rated by the CPU is divided into two parts: a page number (p) and a p
age offset (d). The page number is used as an index into a page table. The page
table contains the base address of each page in physical memory. This base addre
ss is combined with the page offset to define the physical memory address that i
s sent to the memory unit. The paging model of memory is shown in Figure 9.7. T
he page size (like the frame size) is defined by the hardware. The size of a pag
e is typically a power of 2, varying between 512 bytes and 16 MB per page, depen
ding on the computer architecture. The selection of a power of 2 as a page size
makes the translation of a logical address into a page number and page offset pa
rticularly easy.