Download signal

Operating Systems Part – M12
Synchronization
Semaphores
Monitors
Florina Ciorba
03 November 2015
Today’s Overview
•  Open questions from 30.10.2015
•  Synchronization
•  Semaphores, deadlocks
•  Classical problems
– Bounded-buffer
– Readers and writers
– Dining-philosophers
•  Monitors
•  Equivalence of the synchronization primitives
Computer Architecture and Operating Systems, Florina Ciorba, 03.11.15
Operating Systems Concepts
3
Synchronization
•  Definition: Coordination of cooperating processes that share a logical address
space (code and data)
•  Goal: Maintain data consistency
Computer Architecture and Operating Systems, Florina Ciorba, 03.11.15
Operating Systems Concepts
7
Synchronization (Continued)
Operating Systems Concepts, 5th Edition, by Silberschatz, Galvin and Gagne
•  Slides 6.25 – 6.32, 6.40 – 6.47
•  Semaphores, deadlocks
•  Classic synchronization problems
Bounded buffer, reader/writer, dining philosophers
•  Monitors
Computer Architecture and Operating Systems, Florina Ciorba, 03.11.15
Operating Systems Concepts
8
Example: Critical Section for n Processes
• Shared variables
– var mutex : semaphore
– initially mutex = 1
• Process Pi
repeat
wait(mutex);
critical section
signal(mutex);
remainder section
until false;
Operating System Concepts
6.17
c
Silberschatz and Galvin ⃝1998
Semaphore Implementation
• Define a semaphore as a record
type semaphore = record
value: integer;
L: list of process;
end;
• Assume two simple operations:
– block suspends the process that invokes it.
– wakeup(P) resumes the execution of a blocked process P.
Operating System Concepts
6.18
c
Silberschatz and Galvin ⃝1998
Implementation (Cont.)
• Semaphore operations now defined as
wait(S):
S.value := S.value − 1;
if S.value < 0
then begin
add this process to S.L;
block;
end;
signal(S): S.value := S.value + 1;
if S.value ≤ 0
then begin
remove a process P from S.L;
wakeup(P);
end;
Operating System Concepts
6.19
c
Silberschatz and Galvin ⃝1998
Semaphore as General Synchronization Tool
• Execute B in Pj only after A executed in Pi
• Use semaphore flag initialized to 0
• Code:
Operating System Concepts
Pi
..
.
Pj
..
.
A
wait(flag)
signal(flag)
B
6.20
c
Silberschatz and Galvin ⃝1998
Deadlock and Starvation
• Deadlock – two or more processes are waiting indefinitely for
an event that can be caused by only one of the waiting
processes.
• Let S and Q be two semaphores initialized to 1
P1
P0
wait(S);
wait(Q);
wait(Q);
..
.
wait(S);
..
.
signal(S);
signal(Q);
signal(Q);
signal(S);
• Starvation – indefinite blocking. A process may never be
removed from the semaphore queue in which it is suspended.
Operating System Concepts
6.21
c
Silberschatz and Galvin ⃝1998
Synchronization, Critical Section, Deadlock
Synchronization instruments enable coordinated access to critical resources and
critical regions
However by the use of synchronization instruments a system may arrive into a
blocked state (deadlock)
Example: Reservation of two mutexes in false order
Computer Architecture and Operating Systems, Florina Ciorba, 03.11.15
Operating Systems Concepts 14
Description of “Deadlocks”
A number of processes are in a deadlock state if…
1.  All processes wait for a list of results
2.  Each of these results can only be produced by one of these processes
“Livelock” differences
•  The concurrent system is not blocked
•  No progress can, however, be made
Computer Architecture and Operating Systems, Florina Ciorba, 03.11.15
Operating Systems Concepts 15
Deadlock Conditions
The four conditions for deadlocks
1.  Mutual exclusion of resources (no sharing)
E.g., critical sections
2.  Hold and wait
A process can hold a resource and wait for another
3.  No preemption
A process will release a resource voluntarily
4.  Circular wait
If cycles exist within the
resource allocation graph
Computer Architecture and Operating Systems, Florina Ciorba, 03.11.15
Operating Systems Concepts 16
Deadlock Handling Strategies
•  Deadlock Prevention
Ensure that one of the 4 conditions does not occur
E.g., That not all resources are allocated in a single action
•  Deadlock Avoidance
E.g., At allocation time check for circular wait conditions
•  Deadlock Detection
Check the wait conditions only in case of suspicion of deadlock
•  Ignore the problem
Do nothing, on the rationale that deadlocks rarely occur (→ Unix)
Computer Architecture and Operating Systems, Florina Ciorba, 03.11.15
Operating Systems Concepts 17
Classical Problems of Synchronization
• Bounded-Buffer Problem
• Readers and Writers Problem
• Dining-Philosophers Problem
Operating System Concepts
6.25
c
Silberschatz and Galvin ⃝1998
Bounded-Buffer Problem
• Shared data
type item = ...
var buffer = ...
full, empty, mutex: semaphore;
nextp, nextc: item;
full := 0; empty := n; mutex := 1;
Operating System Concepts
6.26
c
Silberschatz and Galvin ⃝1998
Bounded-Buffer Problem (Cont.)
• Producer process
repeat
...
produce an item in nextp
...
wait(empty);
wait(mutex);
...
add nextp to buffer
...
signal(mutex);
signal(full);
until false;
Operating System Concepts
6.27
c
Silberschatz and Galvin ⃝1998
Bounded-Buffer Problem (Cont.)
• Consumer process
repeat
wait(full);
wait(mutex);
...
remove an item from buffer to nextc
...
signal(mutex);
signal(empty);
...
consume the item in nextc
...
until false;
Operating System Concepts
6.28
c
Silberschatz and Galvin ⃝1998
Readers–Writers Problem
• Shared data
var mutex, wrt: semaphore (= 1);
readcount : integer (= 0);
• Writer process
wait(wrt);
...
writing is performed
...
signal(wrt);
Operating System Concepts
6.29
c
Silberschatz and Galvin ⃝1998
Readers–Writers Problem (Cont.)
• Reader process
wait(mutex);
readcount := readcount + 1;
if readcount = 1 then wait(wrt);
signal(mutex);
...
reading is performed
...
wait(mutex);
readcount := readcount − 1;
if readcount = 0 then signal(wrt);
signal(mutex);
Operating System Concepts
6.30
c
Silberschatz and Galvin ⃝1998
Dining-Philosophers Problem
RICE
• Shared data
var chopstick: array [0..4] of semaphore;
(=1 initially)
Operating System Concepts
6.31
c
Silberschatz and Galvin ⃝1998
Dining-Philosophers Problem (Cont.)
• Philosopher i:
repeat
wait(chopstick[i]);
wait(chopstick[i+1 mod 5]);
...
eat
...
signal(chopstick[i]);
signal(chopstick[i+1 mod 5]);
...
think
...
until false;
Operating System Concepts
6.32
c
Silberschatz and Galvin ⃝1998
Monitors
Synchronization concept of programming languages: “Monitor”
•  Semaphore-based programming can lead to simple errors (e.g., request of a
mutex, but forgetting to release it; or incorrect order of request and release)
signal(mutex)
wait(mutex)
...
...
critical section
critical section
signal(mutex)
...
critical section
...
...
...
wait(mutex)
wait(mutex)
wait(mutex)
...
critical section
...
•  Therefore: Another way to express synchronization, coupled with well-known
programming concept: Procedure call
•  Compiler (!) “translates” a procedure call with the additionally required
synchronization actions
Computer Architecture and Operating Systems, Florina Ciorba, 03.11.15
Operating Systems Concepts 26
Monitors
• High-level synchronization construct that allows the safe
sharing of an abstract data type among concurrent processes.
type monitor-name = monitor
variable declarations
procedure entry P1 ( ... );
begin ... end;
procedure entry P2 ( ... );
begin ... end;
..
.
procedure entry Pn ( ... );
begin ... end;
begin
initialization code
end.
Operating System Concepts
6.40
c
Silberschatz and Galvin ⃝1998
6.7
Monitors
247
shared data
operations
initialization
code
Computer Architecture and Operating Systems, Florina Ciorba, 03.11.15
Figure 6.17
Operating Systems Concepts 28
Schematic view of a monitor.
Monitors (Cont.)
• To allow a process to wait within the monitor, a condition
variable must be declared, as:
var x,y: condition
• Condition variable can only be used with the operations wait
and signal.
– The operation
x.wait;
means that the process invoking this operation is
suspended until another process invokes
x.signal;
– The x.signal operation resumes exactly one suspended
process. If no process is suspended, then the signal
operation has no effect.
Operating System Concepts
6.41
c
Silberschatz and Galvin ⃝1998
248
Chapter 6
Monitors (With Condition Variables)
P: x.signal()
queues associated with {
x, y conditions
Q
...
operations
initialization
Signal and wait
code
Signal and continue
Signal and leave (Concurrent Pascal)
Computer Architecture and Operating Systems, Florina Ciorba, 03.11.15
Figure 6.18
Monitor with condition variables.
Operating Systems Concepts 30
Dining Philosophers Example
type dining-philosophers = monitor
var state : array [0..4] of (thinking, hungry, eating);
var self : array [0..4] of condition;
procedure entry pickup (i: 0..4);
begin
state[i] := hungry;
test (i);
if state[i] ̸= eating then self[i].wait;
end;
procedure entry putdown (i: 0..4);
begin
state[i] := thinking;
test (i+4 mod 5);
test (i+1 mod 5);
end;
Operating System Concepts
6.42
c
Silberschatz and Galvin ⃝1998
Dining Philosophers (Cont.)
procedure test (k: 0..4);
begin
if state[k+4 mod 5] ̸= eating
and state[k] = hungry
and state[k+1 mod 5] ̸= eating
then begin
state[k] := eating;
self[k].signal;
end;
end;
begin
for i := 0 to 4
do state[i] := thinking;
end.
Operating System Concepts
6.43
c
Silberschatz and Galvin ⃝1998
Dining Philosophers (Continued)
dining-philosophers.pickup(i)
...
eat
...
dining-philosophers.putdown(i)
This solution ensures
•  No two neighbors are eating simultaneously (test procedure)
•  No deadlocks
But
•  Starvation to death can occur
Monitors: Implementation Using Semaphores
Semaphores serve here as queues
Computer Architecture and Operating Systems, Florina Ciorba, 03.11.15
Operating Systems Concepts 34
Monitor Implementation Using Semaphores
• Variables
var mutex: semaphore (init = 1)
next: semaphore (init = 0)
next-count: integer (init = 0)
• Each external procedure F will be replaced by
wait(mutex);
...
body of F;
...
if next-count > 0
then signal(next)
else signal(mutex);
• Mutual exclusion within a monitor is ensured.
Operating System Concepts
6.44
c
Silberschatz and Galvin ⃝1998
Monitor Implementation (Cont.)
• For each condition variable x, we have:
var x-sem: semaphore (init = 0)
x-count: integer (init = 0)
• The operation x.wait can be implemented as:
x-count := x-count + 1;
if next-count > 0
then signal(next)
else signal(mutex);
wait(x-sem);
x-count := x-count − 1;
Operating System Concepts
6.45
c
Silberschatz and Galvin ⃝1998
Monitor Implementation (Cont.)
• The operation x.signal can be implemented as:
if x-count > 0
then begin
next-count := next-count + 1;
signal(x-sem);
wait(next);
next-count := next-count − 1;
end;
Operating System Concepts
6.46
c
Silberschatz and Galvin ⃝1998
Monitor Implementation (Cont.)
• Conditional-wait construct: x.wait(c);
– c – integer expression evaluated when the wait operation is
executed.
– value of c (priority number) stored with the name of the
process that is suspended.
– when x.signal is executed, process with smallest associated
priority number is resumed next.
• Check two conditions to establish correctness of system:
– User processes must always make their calls on the monitor
in a correct sequence.
– Must ensure that an uncooperative process does not ignore
the mutual-exclusion gateway provided by the monitor, and
try to access the shared resource directly, without using the
access protocols.
Operating System Concepts
6.47
c
Silberschatz and Galvin ⃝1998
Unix Kernel and Monitor Semantic
The Unix kernel behaves as a monitor
•  Monitor method/procedure = Unix system call
Instead of compiler-generated instructions: Trap
•  Only 1 process is active in kernel mode
(this is limited only in part in today’s Linux)
•  Blocking in kernel mode
Explicit wait queue for “conditions” (e.g., device ready)
•  A difference in Unix: If a resource/result is signaled, then all waiting processes
are awoken
Computer Architecture and Operating Systems, Florina Ciorba, 03.11.15
Operating Systems Concepts 39
Shared Memory vs Message Passing
Semaphore, Monitor
•  Require access to common address space for
•  Coordination (change the number of semaphores, etc.)
•  Data exchange (the main reason for coordinating access)
•  Potentially also common code (in case of monitor)
How do concurrent processes coordinate without shared memory?
•  Message exchange/passing via a “mediator” (or medium)
•  Such as the operating system (single-CPU systems)
•  Data bus (multiprocessor computer)
•  Data network (Ethernet, Infiniband)
Computer Architecture and Operating Systems, Florina Ciorba, 03.11.15
Operating Systems Concepts 40
Message Passing
•  send() and receive()
•  These are usually blocking services
•  Due to the potential of blocking, send/receive may be used for synchronization
This is also the employed “solution” in the producer-consumer scenarios in Unix:
Producer: (blocking) write () → Consumer: (blocking) read()
Computer Architecture and Operating Systems, Florina Ciorba, 03.11.15
Operating Systems Concepts 41
Equivalence of the Synchronization Primitives
Semaphores, monitors, and message passing have the same potency (in a
shared memory environment): founded on circular implementability
Meldungs−
austausch
implementierbar mit
Monitor
implementierbar mit
Semaphor
implementierbar mit
•  Case 1: Implementation of message passing with monitors:
Construct “buffer-manager monitor” with send/receive methods
•  Case 2: Implementation of a monitor with semaphores:
Through construction
Computer Architecture and Operating Systems, Florina Ciorba, 03.11.15
Operating Systems Concepts 42
Implementation of Semaphores with Message Passing
(Case 3) Approach
•  Create a process S which will process the “wait/signal” requests
•  We assume blocking send/receive primitives
•  wait(mutex)
send(S, WAIT_REQUEST);
receive(S, CONFIRMATION);
•  signal(mutex)
send(S, SIGNAL_REQUEST);
receive(S, CONFIRMATION);
Computer Architecture and Operating Systems, Florina Ciorba, 03.11.15
Operating Systems Concepts 43
Semaphore with Message Passing (Cont.), “Server”
int count = 1 /* initial semaphore value */
for (; ;) {
p = receive(*, &msg);
if (msg == WAIT_REQUEST) {
if (cnt-- > 0) send(p, CONFIRMATION);
else insert_in_queue(p);
} else if (msg == SIGNAL_REQUEST) {
send(p, CONFIRMATION);
if (count++ < 0)
send(remove_from_queue(), CONFIRMATION);
}
}
Computer Architecture and Operating Systems, Florina Ciorba, 03.11.15
Operating Systems Concepts 44
Programming Concurrency
Concurrency can be “supported” at various levels
•  Hardware
•  Multiprocessor (multi-CPUs)
•  Process
•  Multitasking: 1 CPU is divided among N processes
•  Example: time sharing systems
•  “Sub-process” level
•  Independent activities within a single process
•  Example: multimedia applications (video output, icon refresh)
Computer Architecture and Operating Systems, Florina Ciorba, 03.11.15
Operating Systems Concepts 45
Thread = “Lightweight Process”
•  A thread is an abstract CPU activity
•  With own instruction/program counter (PC)
•  With own data stack
•  With own register set
•  Multiple thread can execute the same code
•  Threads belong to one (heavyweight) process, which bundles all OS resources
•  Code
•  Data storage
•  OS resources (console, data, execution rights, etc.)
Computer Architecture and Operating Systems, Florina Ciorba, 03.11.15
Operating Systems Concepts 46
Differences in Type/Implementation of Threads
a)  Standard Unix: no thread support
b)  User space: simulated threads, e.g., pthread library
c)  Kernel threads: OS can block individual user space threads
Computer Architecture and Operating Systems, Florina Ciorba, 03.11.15
Operating Systems Concepts 47
What Have We Learned Today?
•  Synchronization
•  Semaphores
•  Deadlocks
•  Classical problems
– Bounded-buffer
– Readers and writers
– Dining-philosophers
•  Monitors
•  Equivalence of the synchronization primitives
Computer Architecture and Operating Systems, Florina Ciorba, 03.11.15
Operating Systems Concepts 48