Lecture 6
Semaphores and Monitors
Semaphores
Mutex with semaphores
Synchronization with semaphores
Producer/consumer problem
Monitors
Mutex and synchronization with monitors
Copyright William Stallings 2013
30
30.1.2013
Copyright William Stallings 2013
31
30.1.2013
Semaphore
A variable that has an
integer value upon
which only three
operations are
defined:
There is no way to
inspect or manipulate
semaphores other
than these three
operations
1) May be initialized to a nonnegative integer value
2) The semWait operation decrements the value
3) The semSignal operation increments the value
Copyright William Stallings 2013
32
30.1.2013
Consequences
There is no way to
know before a
process decrements
a semaphore
whether it will block
or not
Copyright William Stallings 2013
There is no way to
know which process
will continue
immediately on a
uniprocessor
system when two
processes are
running concurrently
33
You don’t know
whether another
process is waiting
so the number of
unblocked
processes may be
zero or one
30.1.2013
Semaphore Primitives
queue for strong semaphores
list for weak semaphores
wait, down, P, passeren, take
signal, up, V, vrijgeven, release
Copyright William Stallings 2013
34
30.1.2013
Binary Semaphore Primitives
Copyright William Stallings 2013
35
30.1.2013
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
Copyright William Stallings 2013
36
30.1.2013
D gives
something to
A, B, and C.
for this semaphore
Copyright William Stallings 2013
37
30.1.2013
”permit count” = 1 for mutex protection
Copyright William Stallings 2013
38
30.1.2013
critical region, i.e., critical section
Copyright William Stallings 2013
39
30.1.2013
Producer/Consumer
Problem
General
Situation:
The Problem:
• one or more producers
are generating data and
placing these in a buffer
• a single consumer is
taking items out of the
buffer one at time
• only one producer or
consumer may access
the buffer at any one
time
Copyright William Stallings 2013
40
• ensure that the
producer can’t add
data into full buffer
and consumer can’t
remove data from
an empty buffer
Can have also many consumers
30.1.2013
Buffer Structure
”infinite” buffer is a buffer that can not overflow,
no need to worry about buffer overflow!
Copyright William Stallings 2013
41
30.1.2013
Incorrect
producer /
consumer
solution
(binary
sema-sema
phores))
phores
Copyright William Stallings 2013
Many problems,
failing scenario?
42
Figure 5.9 An Incorrect Solution
30.1.2013
Copyright William Stallings 2013
43
30.1.2013
Correct
producer /
What is the purpose
of each semaphore?
consumer
Why only the
consumer waits?
solution
(binary
sema-sema
phores))
phores
Why is m needed?
Figure 5.10
Copyright William Stallings 2013
44
30.1.2013
Producer /
Consumer,
mutex
solution
infinite
buffer,,
buffer
synchronization
solution
(general)
sema-sema
mutex
solution
phores
Figure 5.11
Discuss
Copyright William Stallings 2013
45
30.1.2013
Copyright William Stallings 2013
46
30.1.2013
Producer /
s = mutex
e = space in buffer
n = data in buffer
Consumer,
finite
synchronize
for empty slot
in buffer
buffer,,
buffer
(general)
sema-sema
synchronize
for full slot in
buffer
phores
Figure 5.13
Discuss
Copyright William Stallings 2013
47
30.1.2013
Implementation of
Semaphores
Imperative that the semWait and
semSignal operations be implemented as
atomic primitives
Can be implemented in hardware or firmware
Dekker, Peterson
hardware-support
Copyright William Stallings 2013
48
30.1.2013
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
Copyright William Stallings 2013
49
30.1.2013
Monitor Characteristics
Local data variables
are accessible only
by the monitor’s
procedures and not
by any external
procedure
Global data not
accessible from
monitor
Copyright William Stallings 2013
Only one process
may be executing in
the monitor at a time
Process enters
monitor by invoking
one of its
procedures
(methods)
50
30.1.2013
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
always suspends!
csignal(c): resume execution of some process
blocked after a cwait on the same condition
No values to remember old csignals!
Copyright William Stallings 2013
51
30.1.2013
Copyright William Stallings 2013
52
Figure 5.15 Structure of a Monitor
30.1.2013
Declaration and CWait
Condition CV
Declare new condition variable
No value, just fifo queue of waiting processes
CWait( CV )
Always suspends, process placed in queue
Unlocks monitor mutex
Allows someone else into monitor?
Allows another process awakened from (another?) CWait
to proceed?
Allows process that lost mutex in CSignal to proceed?
When awakened, waits for mutex lock to proceed
Not really ready-to-run yet
30.1.2013
Copyright Teemu Kerola 2013
53
CSignal
Wakes up first waiting process, if any
Which one continues execution in monitor (in mutex)?
The process doing the signalling? (Lampson & Redell)
The process just woken up? (Hoare, original)
Some other processes trying to get into monitor? No.
Two signalling disciplines (two signalling semantics)
Signal and continue - signalling process keeps mutex
Signal and wait - signalled process gets mutex
If no one was waiting, signal is lost (no memory)
Advanced signalling (with memory) must be handled in some
other manner
Local counters in monitor
Copyright Teemu Kerola 2013
54
30.1.2013
Signaling Semantics
Signal and Wait
CSignal (CV )
Hoare
Awakened (signalled) process executes immediately
Mutex baton passing
No one else can get the mutex lock at this time
Condition waited for is certainly true when process resumes
execution
Signaller waits in mutex lock
With other processes trying to enter the semaphore
Process may lose mutex at any signal operation
But does not lose, if no one was waiting!
Problem, if critical section would continue over CSignal
Copyright Teemu Kerola 2013
55
30.1.2013
Signaling Semantics
Signal and Continue CSignal( CV )
Lampson & Redell
Signalling process continues
Mutex can not terminate at signal operation
Awakened (signalled) process will wait in mutex lock
With other processes trying to enter the semaphore
May not be the next one active
Many control variables signalled by one process?
Condition waited for may not be true any more once awaked
process resumes (becomes active again)
Need while-loop to test for condition again?
Copyright Teemu Kerola 2013
56
30.1.2013
Hoare
57
Copyright William
2013
FigureStallings
5.16 A
Solution
to the Bounded-Buffer Producer/Consumer Problem Using a Monitor30.1.2013
Another Producer/Consumer with
Monitor PC
Hoare
Int buf_cnt = 0;
Monitor
condition notEmpty, notFull;
Producer
(size N buffer)
Loop forever
D <- Produce
PC.append_ok(N)
append_tail(buffer, D)
PC.append_done()
Consumer
Loop forever
PC.take_ok()
D <- head(buffer)
PC.take_done()
consume(D)
Copyright Teemu Kerola 2013
58
Operation append_ok(N)
if (buf_cnt==N)
Cwait(notFull)
buf_cnt++;
Operation append_done()
Csignal(notEmpty)
Operation take_ok()
if (buf_cnt==0)
Cwait(notEmpty)
buf_cnt--;
Operation take_done()
Csignal(notFull)
Discuss
Which one is better? Why? 30.1.2013
Summary le06
Semaphores
Synchronization with semaphores
Monitors
Mutex and synchronization with monitors
Differences between semaphores and condition
variables
Producer/consumer problem
Solutions with semaphores and monitor
Copyright William Stallings 2013
59
30.1.2013