Operating

Systems: Chapter 5
Internals Concurrency:
and Design
Principles Mutual Exclusion
and Synchronization
Eighth Edition
By William Stallings
 OperatingSystem design is concerned
with the management of processes and
threads:
 Multiprogramming
 Multiprocessing
 Distributed Processing
 Multiple
Applications
Structured
Applications Operating
invented to allow System
processing time to Structure
be shared among extension of
active applications modular design
and structured
programming OS themselves
implemented as a
set of processes
or threads
Table 5.1

Some Key
Terms
Related
to
Concurrency
 Interleaving and overlapping
 can be viewed as examples of concurrent processing
 both present the same problems

 Uniprocessor – the relative speed of execution of

processes cannot be predicted
 depends on activities of other processes
 the way the OS handles interrupts
 scheduling policies of the OS
 Sharing of global resources
 Difficult
for the OS to manage the allocation
of resources optimally
 Difficultto locate programming errors as
results are not deterministic and
reproducible
 Occurs when multiple processes or
threads read and write data items
 Thefinal result depends on the order of
execution
 the “loser” of the race is the process
that updates last and will determine the
final value of the variable
 Operating System Concerns
 Design and management issues raised by the existence of
concurrency:
 The OS must:

be able to keep track of various processes

allocate and de-allocate resources for each active process

protect the data and physical resources of each process

against interference by other processes

ensure that the processes and outputs are independent of the

processing speed
Degree of Awareness Relationship I nfluence that One Potential Control
Process Has on the Problems
Other

Processes unaware of Competition •Results of one •Mutual exclusion

Table 5.2
each other process independent
of the action of •Deadlock (renewable
others resource) Process
•Timing of process
may be affected
•Starvation Interaction

Processes indirectly Cooperation by •Results of one •Mutual exclusion

aware of each other sharing process may depend
(e.g., shared object) on information •Deadlock (renewable
obtained from others resource)

•Timing of process •Starvation

may be affected
•Data coherence

Processes directly Cooperation by •Results of one •Deadlock

aware of each other communication process may depend (consumable
(have communication on information resource)
primitives available to obtained from others
them) •Starvation
•Timing of process
may be affected
 Resource Competition
 Concurrent processes come into conflict when they
are competing for use of the same resource
 for example: I/O devices, memory, processor time, clock

In the case of competing processes three

control problems must be faced:

• the need for mutual exclusion

• deadlock
• starvation
 Figure 5.1
Illustration of Mutual Exclusion

PROCESS 1 * / / * PROCESS 2 * / / * PROCESS n * /

voi d P1 voi d P2 voi d Pn

{ { {
whi l e (true) { whi l e (true) { whi l e (true) {
/* preceding code */; /* preceding code */; • • • /* preceding code */;
entercritical (Ra); entercritical (Ra); entercritical (Ra);
/* critical section */; /* critical section */; /* critical section */;
exitcritical (Ra); exitcritical (Ra); exitcritical (Ra);
/* following code */; /* following code */; /* following code */;
} } }
} } }
 Must be enforced
 A process that halts must do so without
interfering with other processes
 No deadlock or starvation
 A process must not be denied access to a critical section
when there is no other process using it
 No assumptions are made about relative process speeds
or number of processes
 A process remains inside its critical section for a finite
time only
 Interrupt Disabling  Disadvantages:
 uniprocessor system  the efficiency of
execution could be
 disabling interrupts noticeably degraded
guarantees mutual
exclusion  this approach will not
achieves (doesn't affect) mutual exclusion. work in a
multiprocessor
architecture
 Compare&Swap Instruction
 also called a “compare and exchange
instruction”
 a compare is made between a memory value
and a test value
 if the values are the same a swap occurs
 carried out atomically
 Figure 5.2
Hardware Support for Mutual Exclusion
/ * pr ogr am mutualexclusion */ / * pr ogr am mutualexclusion */
const i nt n = /* number of processes */; i nt const n = /* number of processes*/;
i nt bolt; i nt bolt;
voi d P(i nt i) voi d P(i nt i)
{ {
whi l e (true) { whi l e ( true) {
whi l e (compare_and_swap(&bolt, 0, 1) == 1) i nt keyi = 1;
/* do nothing */; do exchange (&keyi, &bolt)
/* critical section */; whi l e (keyi != 0);
bolt = 0; /* critical section */;
/* remainder */; bolt = 0;
} /* remainder */;
} }
voi d mai n( ) }
{ voi d mai n( )
bolt = 0; {
par begi n ( P(1), P(2), . . . ,P(n)); bolt = 0;
par begi n ( P(1), P(2), . . ., P(n));
} }

(a) Compare and swap instruction (b) Exchange instruction

 Applicable to any number of processes on
either a single processor or multiple
processors sharing main memory
 Simple and easy to verify
 It can be used to support multiple critical
sections; each critical section can be defined
by its own variable
 Special Machine Instruction:
Disadvantages
 Busy-waiting is employed, thus while a
process is waiting for access to a critical
section it continues to consume processor
time
 Starvation is possible when a process
leaves a critical section and more than
one process is waiting
 Deadlock is possible
Semaphor e An integer value used for signaling among processes. Only three
operations may be performed on a semaphore, all of which are
atomic: initialize, decrement, and increment. The decrement
operation may result in the blocking of a process, and the increment
operation may result in the unblocking of a process. Also known as a
counting semaphore or a general semaphore
Binary Semaphore
M utex
A semaphore that takes on only the values 0 and 1.
Similar to a binary semaphore. A key difference between the two is
Table 5.3
that the process that locks the mutex (sets the value to zero) must be
the one to unlock it (sets the value to 1).
Condition Variable A data type that is used to block a process or thread until a particular
condition is true. Common
M onitor A programming language construct that encapsulates variables,
access procedures and initialization code within an abstract data type.
The monitor's variable may only be accessed via its access
procedures and only one process may be actively accessing the
monitor at any one time. The access procedures are critical sections. Concurrency
A monitor may have a queue of processes that are waiting to access
it.
Event Flags A memory word used as a synchronization mechanism. Application
code may associate a different event with each bit in a flag. A thread
can wait for either a single event or a combination of events by
Mechanisms
checking one or multiple bits in the corresponding flag. The thread is
blocked until all of the required bits are set (AND) or until at least
one of the bits is set (OR).
M ailboxes/M essages A means for two processes to exchange information and that may be
used for synchronization.
Spinlocks Mutual exclusion mechanism in which a process executes in an
infinite loop waiting for the value of a lock variable to indicate
availability.
 Semaphore
A variable that has
an integer value • There is no way to inspect or
upon which only manipulate semaphores other
three operations are than these three operations
defined:

1) May be initialized to a nonnegative integer value

2) The semWait operation decrements the value
3) The semSignal operation increments the value
 Consequences

There is no way to
There is no way to know which process You don’t know
know before a will continue whether another
process decrements immediately on a process is waiting so
a semaphore uniprocessor system the number of
whether it will when two processes unblocked processes
block or not are running may be zero or one
concurrently
Figure 5.3

A
Definition
of
Semaphore
Primitives
st r uct binary_semaphore {
enum {zero, one} value;
queueType queue;
};
voi d semWaitB(binary_semaphore s)
{
i f ( s.value == one)
s.value = zero;
el se {
/* place this process in s.queue */;
/* block this process */;
}
}
voi d semSignalB(semaphore s)
{
i f (s.queue is empty())
s.value = one;
el se {
/* remove a process P from s.queue */;
/* place process P on ready list */;
}
}

Figure 5.4
A Definition of Binary Semaphore Primitives
 A queue is used to hold processes waiting on the semaphore

Strong Semaphores
• the process that has been blocked the longest is
released from the queue first (FIFO)

Weak Semaphores
• the order in which processes are removed from the
queue is not specified
 A issues semWait, later times out
1 Processor
C D B A D BA C
Ready queue Processor Ready queue
s= 1 s= 0 5

C issues semWait
Blocked queue Blocked queue

Processor
A CD B
Ready queue
s= 0 2

B issues semWait
Blocked queue

Processor Processor
AC D D
Ready queue D issues semSignal Ready queue D issues semSignal
s = –1 3
s = –3 6

B C A B
Blocked queue Blocked queue
D issues semSignal, later times out
4 Processor
B AC D C D
Ready queue Processor Ready queue D issues semSignal
s= 0 s = –2 7

A B
Blocked queue Blocked queue

Figure 5.5 Example of Semaphor e M echanism

 Figure 5.6
Mutual Exclusion Using Semaphores
 Queue for Value of
semaphore lock semaphore lock A B C
Critical
1 region

Normal
semWait(lock)
execution
0
Blocked on
semWait(lock)
semaphore
B –1 lock

semWait(lock)

C B –2
semSignal(lock)

C –1

semSignal(lock)

semSignal(lock)

1
Note that normal
execution can
proceed in parallel
but that critical
regions are serialized.

Figure 5.7 Processes Accessing Shared Data

Protected by a Semaphor e
 Producer/Consumer Problem

General one or more producers are generating data and placing

Statement: these in a buffer
a single consumer is taking items out of the buffer one
at a time
only one producer or consumer may access the buffer
at any one time
The
Problem: ensure that the producer can’t add
data into full buffer and consumer
can’t remove data from an empty
buffer
 0 1 2 3 4

b[1] b[2] b[3] b[4] b[5]

out in

Note: shaded area indicates portion of buffer that is occupied

Figure 5.8 I nfinite Buffer for the Producer/Consumer Problem

/* pr ogr am producerconsumer */
i nt n;
binary_semaphore s = 1, delay = 0; Figure 5.9
voi d producer()
{
whi l e (true) {
produce();
semWaitB(s); An Incorrect
append();
n++;
i f (n==1) semSignalB(delay);
Solution
}
semSignalB(s);
to the
}
voi d consumer() Infinite-Buffer
{
semWaitB(delay);
whi l e (true) {
Producer/Consu
semWaitB(s);
take(); mer
n--;
semSignalB(s);
consume();
Problem Using
}
i f (n==0) semWaitB(delay); Binary
}
voi d main() Semaphores
{
n = 0;
par begi n (producer, consumer);
}
 Table 5.4
Possible Scenario for the Program of Figure 5.9
Producer Consumer s n Delay
1 1 0 0
2 semWaitB(s) 0 0 0
3 n++ 0 1 0
4 i f (n==1) 0 1 1
(semSignalB(delay))
5 semSignalB(s) 1 1 1
6 semWaitB(delay) 1 1 0
7 semWaitB(s) 0 1 0
8 n-- 0 0 0
9 semSignalB(s) 1 0 0
10 semWaitB(s) 0 0 0
11 n++ 0 1 0
12 i f (n==1) 0 1 1
(semSignalB(delay))
13 semSignalB(s) 1 1 1
14 i f (n==0) (semWaitB(delay)) 1 1 1
15 semWaitB(s) 0 1 1
16 n-- 0 0 1
Note: White semSignalB(s)
areas
17 1 0 1
18 i f (n==0) (semWaitB(delay)) 1 0 0
represent the
critical 19 semWaitB(s) 0 0 0
section
controlled by 20 n-- 0 –1 0
semaphore 21 semSignalB(s) 1 –1 0
s.
 Figure 5.10

A Correct
Solution to the
Infinite-Buffer
Producer/Cons
umer Problem
Using Binary
Semaphores
 /* pr ogr am producerconsumer */
semaphore n = 0, s = 1;
voi d producer()
Figure 5.11 {
whi l e (true) {
produce();
A Solution semWait(s);
append();
to the semSignal(s);
Infinite- semSignal(n);
Buffer }
}
Producer/C voi d consumer()
onsumer {
whi l e (true) {
Problem semWait(n);
Using semWait(s);
Semaphores take();
semSignal(s);
consume();
}
}
voi d main()
{
par begi n (producer, consumer);
}
b[1] b[2] b[3] b[4] b[5] b[n]

out in

(a)

b[1] b[2] b[3] b[4] b[5] b[n]

in out

(b)

Figure 5.12 Finite Circular Buffer for the Producer/Consumer Problem

 Figure 5.13

A Solution to
the Bounded-
Buffer
Producer/Cons
umer Problem
Using
Semaphores
 Implementation of
Semaphores
 Imperativethat the semWait and
semSignal operations be implemented as
atomic primitives
 Can be implemented in hardware or firmware
 Software schemes such as Dekker’s or
Peterson’s algorithms can be used
 Useone of the hardware-supported
schemes for mutual exclusion
 Figure 5.14
Two Possible Implementations of Semaphores

semWait(s) semWait(s)
{ {
whi l e ( compare_and_swap(s.flag, 0 , 1) == 1) inhibit interrupts;
/* do nothing */; s.count--;
s.count--; i f (s.count < 0) {
i f (s.count < 0) { /* place this process in s.queue */;
/* place this process in s.queue*/; /* block this process and allow interrupts */;
/* block this process (must also set s.flag to 0) }
*/; el se
} allow interrupts;
s.flag = 0; }
}
semSignal(s)
semSignal(s) {
{ inhibit interrupts;
whi l e ( compare_and_swap(s.flag, 0 , 1) == 1) s.count++;
/* do nothing */; i f (s.count <= 0) {
s.count++; /* remove a process P from s.queue */;
i f (s.count <= 0) { /* place process P on ready list */;
/* remove a process P from s.queue */; }
/* place process P on ready list */; allow interrupts;
} }
s.flag = 0;
}

(a) Compare and Swap Instruction (b) Interrupts

 Monitors
 Programming language construct that provides
equivalent functionality to that of semaphores and is
easier to control
 Implemented in a number of programming
languages
 including Concurrent Pascal, Pascal-Plus, Modula-2,
Modula-3, and Java
 Has also been implemented as a program library
 Software module consisting of one or more
procedures, an initialization sequence, and local
data
 Monitor Characteristics
Local data variables are accessible only by the monitor’s
procedures and not by any external procedure

Process enters monitor by invoking one of its procedures

Only one process may be executing in the monitor at a time

 Synchronization
 Achieved by the use of condition variables that are
contained within the monitor and accessible only
within the monitor
 Condition variables are operated on by two
functions:
 cwait(c): suspend execution of the calling process on
condition c
 csignal(c): resume execution of some process blocked
after a cwait on the same condition
 queue of
entering
processes

monitor waiting area Entrance

M ONI TOR

condition c1 local data

cwait(c1)
condition variables

Procedure 1

condition cn

cwait(cn)
Procedure k

urgent queue

csignal
initialization code

Exit

Figure 5.15 Structure of a M onitor

 Figure 5.16

A Solution to the
Bounded-Buffer
Producer/Consu
mer Problem
Using a Monitor
 When processes interact with one another two
fundamental requirements must be satisfied:

synchronization communication

• to enforce mutual • to exchange

exclusion information

 Message Passing is one approach to providing both

of these functions
 works with distributed systems and shared memory multiprocessor and
uniprocessor systems
 Message Passing
 The actual function is normally provided in the form
of a pair of primitives:
send (destination, message)
receive (source, message)
 A process sends information in the form of a message
to another process designated by a destination
 A process receives information by executing the
receive primitive, indicating the source and the
message
Synchronization Format
Send Content
blocking Length
nonblocking fixed
Receive variable
blocking
nonblocking Queueing D iscipline
test for arrival FIFO
Priority
Addressing
Direct
send
receive
explicit
implicit
Indirect
static
dynamic
ownership

Table 5.5
Design Characteristics of Message Systems for
Interprocess Communication and Synchronization
 Bothsender and receiver are blocked until
the message is delivered
 Sometimes referred to as a rendezvous
 Allowsfor tight synchronization between
processes
 Nonblocking Send
Nonblocking send, blocking receive
• sender continues on but receiver is blocked until the
requested message arrives
• most useful combination
• sends one or more messages to a variety of destinations as
quickly as possible
• example -- a service process that exists to provide a service
or resource to other processes

Nonblocking send, nonblocking receive

• neither party is required to wait
 Schemes for specifying processes in send
and receive primitives fall into two
categories:

Direct Indirect
addressing addressing
 Direct Addressing
 Send primitive includes a specific identifier
of the destination process
 Receive primitive can be handled in one of
two ways:
 require that the process explicitly
designate a sending process
 effective for cooperating concurrent processes
 implicit addressing
 source parameter of the receive primitive possesses a
value returned when the receive operation has been
performed
 Indirect Addressing

Messages are sent to a

shared data structure Queues are
consisting of queues that referred to as
can temporarily hold mailboxes
messages

Allows for One process sends a

greater flexibility message to the mailbox
and the other process
in the use of picks up the message
messages from the mailbox
 S1

S1 M ailbox R1 Port R1

Sn

(a) One to one (b) M any to one

R1 S1 R1

S1 M ailbox M ailbox

Rm Sn Rm

(c) One to many (d) M any to many

Figure 5.18 I ndirect Process Communication

 M essage Type
Destination I D
Header Source I D
M essage Length
Control I nformation

Body M essage Contents

Figure 5.19 General M essage Format

 Figure 5.20
Mutual Exclusion Using Messages
 Figure 5.21
A Solution to the
Bounded-Buffer
Producer/Consum
er Problem Using
Messages
 Readers/Writers Problem
 A data area is shared among many processes
 some processes only read the data area, (readers)
and some only write to the data area (writers)
 Conditions that must be satisfied:
1. any number of readers may simultaneously
read the file
2. only one writer at a time may write to the file
3. if a writer is writing to the file, no reader
may read it
Figure 5.22

A Solution to
the
Readers/Write
rs Problem
Using
Semaphores:
Readers Have
Priority
Readers only in the system •wsem set
•no queues

Writers only in the system •wsem and rsem set

•writers queue on wsem

Both readers and writers with read first •wsem set by reader
•rsem set by writer
•all writers queue on wsem
•one reader queues on rsem
•other readers queue on z

Both readers and writers with write first •wsem set by writer
•rsem set by writer
•writers queue on wsem
•one reader queues on rsem
•other readers queue on z

Table 5.6
State of the Process Queues for Program of Figure 5.23
 Figure 5.23
A Solution to the
Readers/Writers
Problem Using
Semaphores:
Writers Have
Priority
voi d reader(int i) voi d controller()
{ {
message rmsg; whi l e (true)
whi l e (true) { {
rmsg = i; i f (count > 0) {
send (readrequest, rmsg); i f ( ! empty (finished)) {
receive (mbox[i], rmsg); receive (finished, msg);
READUNIT (); count++;
rmsg = i; }
send (finished, rmsg); el se i f ( !empty (writerequest)) {
} receive (writerequest, msg);
} writer_id = msg.id;
voi d writer(int j) count = count – 100;
{ }
message rmsg; el se i f ( !empty (readrequest)) {
whi l e(true) { receive (readrequest, msg);
rmsg = j; count--;
send (writerequest, rmsg); send (msg.id, "OK");
receive (mbox[j], rmsg); }
WRITEUNIT (); }
rmsg = j; i f (count == 0) {
send (finished, rmsg); send (writer_id, "OK");
} receive (finished, msg);
} count = 100;
}
whi l e (count < 0) {
receive (finished, msg);
count++;
}
}
}

Figure 5.24

A Solution to the Readers/Writers Problem Using Message Passing

 Summary
 Principles of concurrency  Monitors
 Race condition  Monitor with signal
 OS concerns  Alternate model of monitors with
 Process interaction notify and broadcast
 Requirements for mutual
exclusion  Message passing
 Synchronization
 Mutual exclusion: hardware support  Addressing
 Interrupt disabling
 Message format
 Special machine instructions
 Queueing discipline
 Semaphores  Mutual exclusion
 Mutual exclusion
 Producer/consumer problem
 Readers/writers problem
 Implementation of semaphores  Readers have priority
 Writers have priority