|
|
|
Modern Operating Systems by Herbert Bos and Andrew S. Tanenb...
Modern_Operating_Systems_by_Herbert_Bos_and_Andrew_S._Tanenbaum_4th_Ed.pdf
Showing 153-154 out of 1137
Modern Operating Systems by Herbert Bos and Andrew...
Modern_Operating_Systems_by_Herbert_Bos_and_Andrew_S._Tanenbaum_4th_Ed.pdf-M ODERN O PERATING S YSTEMS
Modern Operating Systems by Herbert...
Modern_Operating_Systems_by_Herbert_Bos_and_Andrew_S._Tanenbaum_4th_Ed.pdf-M ODERN O PERATING S YSTEMS
Page 153
122
PROCESSES AND THREADS
CHAP. 2
A enters critical region
A leaves critical region
B attempts to
enter critical
region
B enters
critical region
T
1
T
2
T
3
T
4
Process A
Process B
B blocked
B leaves
critical region
Time
Figure 2-22.
Mutual exclusion using critical regions.
2.3.3 Mutual Exclusion with Busy Waiting
In this section we will examine various proposals for achieving mutual exclu-
sion, so that while one process is busy updating shared memory in its critical re-
gion, no other process will enter
its
critical region and cause trouble.
Disabling Interrupts
On a single-processor system, the simplest solution is to have each process dis-
able all interrupts just after entering its critical region and re-enable them just be-
fore leaving it. With interrupts disabled, no clock interrupts can occur.
The CPU is
only switched from process to process as a result of clock or other interrupts, after
all, and with interrupts turned off the CPU will not be switched to another process.
Thus, once a process has disabled interrupts, it can examine and update the shared
memory without fear that any other process will intervene.
This approach is generally unattractive because it is unwise to give user proc-
esses the power to turn off interrupts. What if one of them did it, and never turned
them on again? That could be the end of the system. Furthermore, if the system is
a multiprocessor (with two or more CPUs) disabling interrupts affects only the
CPU that executed the
disable
instruction. The other ones will continue running
and can access the shared memory.
On the other hand, it is frequently convenient for the kernel itself to disable in-
terrupts for a few instructions while it is updating variables or especially lists.
If
an interrupt occurrs while the list of ready processes, for example, is in an incon-
sistent state, race conditions could occur. The conclusion is: disabling interrupts is
Page 154
SEC. 2.3
INTERPROCESS COMMUNICATION
123
often a useful technique within the operating system itself but is not appropriate as
a general mutual exclusion mechanism for user processes.
The possibility of achieving mutual exclusion by disabling interrupts—even
within the kernel—is becoming less every day due to the increasing number of
multicore chips even in low-end PCs.
Two cores are already common, four are
present in many machines, and eight, 16, or 32 are not far behind.
In a multicore
(i.e., multiprocessor system) disabling the interrupts of one CPU does not prevent
other CPUs from interfering with operations the first CPU is performing. Conse-
quently, more sophisticated schemes are needed.
Lock Variables
As a second attempt, let us look for a software solution. Consider having a sin-
gle, shared (lock) variable, initially 0.
When a process wants to enter its critical re-
gion, it first tests the lock.
If the lock is 0, the process sets it to 1 and enters the
critical region. If the lock is already 1, the process just waits until it becomes 0.
Thus, a 0 means that no process is in its critical region, and a 1 means that some
process is in its critical region.
Unfortunately, this idea contains exactly the same fatal flaw that we saw in the
spooler directory. Suppose that one process reads the lock and sees that it is 0.
Be-
fore it can set the lock to 1, another process is scheduled, runs, and sets the lock to
1. When the first process runs again, it will also set the lock to 1, and two proc-
esses will be in their critical regions at the same time.
Now you might think that we could get around this problem by first reading
out the lock value, then checking it again just before storing into it, but that really
does not help. The race now occurs if the second process modifies the lock just
after the first process has finished its second check.
Strict Alternation
A third approach to the mutual exclusion problem is shown in Fig. 2-23. This
program fragment, like nearly all the others in this book, is written in C.
C was
chosen here because real operating systems are virtually always written in C (or
occasionally C++), but hardly ever in languages like Java, Python, or Haskell. C is
powerful, efficient, and predictable, characteristics critical for writing operating
systems. Java, for example, is not predictable because it might run out of storage at
a critical moment and need to invoke the garbage collector to reclaim memory at a
most inopportune time. This cannot happen in C because there is no garbage col-
lection in C.
A quantitative comparison of C, C++, Java, and four other languages
is given by Prechelt (2000).
In Fig. 2-23, the integer variable
turn
, initially 0, keeps track of whose turn it is
to enter the critical region and examine or update the shared memory. Initially,
process 0 inspects
turn
, finds it to be 0, and enters its critical region. Process 1 also
Ace your assessments! Get Better Grades
Browse thousands of Study Materials & Solutions from your Favorite Schools
Concordia University
Concordia_University
School:
Operating_Systems
Course:
Great resource for chem class. Had all the past labs and assignments
Leland P.
Santa Clara University
Introducing Study Plan
Using AI Tools to Help you understand and remember your course concepts better and faster than any other resource.
Find the best videos to learn every concept in that course from Youtube and Tiktok without searching.
Save All Relavent Videos & Materials and access anytime and anywhere
Prepare Smart and Guarantee better grades
Know more
Students also viewed documents
lab 18.docx
lab_18.docx
Course
Course
3
Module5QuizSTA2023.d...
Module5QuizSTA2023.docx.docx
Course
Course
10
Week 7 Test Math302....
Week_7_Test_Math302.docx.docx
Course
Course
30
Chapter 1 Assigment ...
Chapter_1_Assigment_Questions.docx.docx
Course
Course
5
Week 4 tests.docx.do...
Week_4_tests.docx.docx
Course
Course
23
Week 6 tests.docx.do...
Week_6_tests.docx.docx
Course
Course
106
