Download Chapter 7: Process Synchronization

Critical Regions
§ 7.6
• Although semaphores provide a convenient and
effective mechanism for process synchronization,
their incorrect use can still result in timing errors
that are difficult to detect.
• Examples:
A process omits the wait(mutex),
wait(mutex);
signal(mutex);
or the signal(mutex)
, or both
critical
section
critical
section
wait(mutex);
wait(mutex);
Eitherprocesses
mutual exclusion
Several
may be is
violated in
or their
a deadlock
occur.
executing
criticalwill
section
A deadlock will occur.
simultaneously.
1
Critical Regions
§ 7.6
• Although semaphores provide a convenient and
Multiple
Question:
effectiveChoices
mechanism
for process synchronization,
incorrect
still result
in timingif errors
( their
) What
kinduse
of can
problem
can happen
that
arethan
difficult
detect.work on a semaphore
more
oneto
thread
• Examples:
in the following sequence?
A process omits the wait(mutex),
wait(mutex);
signal(mutex);signal(mutex);
or the signal(mutex)
, oreboth
critical
section
Answer:
criticalSection();
critical
section
wait(mutex);
wait(mutex); wait(mutex);
(a) starvation (b) deadlock (c) blocking
Eitherprocesses
mutual
Several
may be is
(d) not synchronizing
(e)exclusion
violate
mutual
violated in
or their
a deadlock
occur.
criticalwill
section
exclusion executing
A deadlock will occur.
simultaneously.
2
Critical Region
• High-level synchronization construct
• A shared variable v of type T, is declared as:
v:shared T;
• Variable v accessed only inside statement
region v when (B) S;
where B is a boolean expression.
• While statement S is being executed, no
other process can access variable v.
3
Critical Region
• Regions referring to the same shared
variable exclude each other in time.
• When a process tries to execute the region
statement, the Boolean expression B is
evaluated. If B is true, statement S is
executed. If it is false, the process is
delayed until B becomes true and no other
process is in the region associated with v.
4
Critical Region
• Example: two statements
region v when (true) S1;
region v when (true) S2;
are executed concurrently in distinct
sequential processes, the result will be
equivalent to the sequential execution “S1
followed by S2” or “S2 followed by S1.”
5
Critical Region
• The critical-region construct guards against certain
simple errors associated with the semaphore
solution to the critical-section problem that may
be made by a programmer.
• However, it does not necessarily eliminate all
synchronization errors; rather, it reduces their
number.
• Can be used to solve certain general
synchronization problems.
6
Example – bounded buffer
• Shared data:
struct buffer {
item pool[n];
int count, in, out;
}
• Producer process inserts nextp into the shared buffer
region buffer when( count < n) {
pool[in] = nextp;
in = (in+1) % n;
count++;
}
7
Example – bounded buffer
• Consumer process removes an item from
the shared buffer and puts it in nextc
region buffer when (count > 0) {
nextc = pool[out];
out = (out+1) % n;
count--;
}
8
Implement the conditional
critical region (Skip)
9
Monitors
§ 7.7
• High-level synchronization construct that allows
the safe sharing of an abstract data type among
concurrent processes.
• A monitor presents a set of programmerdefined operations that are provided mutual
exclusion within the monitor.
• A monitor type consists of declarations of
variables whose values define the state of an
instance of the type, as well as the bodies of
procedures or functions that implement operations
on the type.
10
Monitor Syntax
monitor monitor-name
{
shared variable declarations
procedure body P1 (…) {
. . .
}
procedure body P2 (…) {
. . .
}
procedure body Pn (…) {
. . .
}
{
}
}
initialization code
11
Condition Variables
• Encapsulation: limits access to the local variables
•
•
•
•
by only the local procedures.
The monitor construct prohibits concurrent access
to all procedures defined within the monitor.
Only one process may be active within the
monitor at a time.
Synchronization is built into the monitor type, the
programmer does not need to code it explicitly.
Special operations wait and signal can be invoked
on the variables of type condition.
condition x, y;
• A process that invokes x.wait is suspended until
another process invokes x.signal
12
Condition Variables
• Encapsulation: limits access to the local variables
True-False
by only theQuestion:
local procedures.
) Although
there maybe
several
processes
•( The
monitor construct
prohibits
concurrent
access
toinside
all procedures
defined
within
monitor.
the monitor
at the
samethe
time,
there
• Only
one process
be active
within
theof
can only
be one may
process
with the
state
monitor
at aa time.
time.
active at
• Synchronization is built into the monitor type, the
programmer does not need to code it explicitly.
• Special
operations
wait and signal can be invoked
Answer:
○
on the variables of type condition.
condition x, y;
• A process that invokes x.wait is suspended until
another process invokes x.signal
13
Schematic View of a Monitor
14
Condition Variables
• Condition variable can only be used with the operations
wait and signal.
Contrast this operation with
– The operation
the signal operation
associated with semaphores,
x.wait();
which
affectsisthe state
means that the process invoking
thisalways
operation
of the semaphore.
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.
15
Monitor with condition variables
16
More reasonable since
P was already
executing in the
monitor.
Two Possibilities
• When x.signal() operation is invoked by a
process P, there is a suspended Advocated
process Q
by Hoare
associated with condition x.
1. P either waits until Q leaves the monitor, or waits
for another condition.
2. Q either waits until P leaves the monitor,
waits for
“logical”orcondition
for another condition.
which Q was waiting
•
may nothe
longer hold by
Concurrent C: when process P executes
the time Q is resumed.
signal operation, process Q is immediately
resumed.
17
Solution to Dining Philosophers
monitor dp
{
enum {thinking, hungry, eating} state[5];
condition self[5];
void pickup(int i)
// following slides
philosopher i can
void putdown(int i)
// following slides
delay herself
void test(int i)
// following
slides
when she is
void init() {
for (int i = 0; i < 5; i++)
hungry, but is
state[i] = thinking;
unable to obtain
}
the chopsticks she
}
needs.
18
pickUp() Procedure
void pickup(int i) {
state[i] = hungry;
test[i];
if (state[i] != eating)
self[i].wait();
}
void putdown(int i) {
state[i] = thinking;
// test left and right neighbors
test((i+4) % 5);
test((i+1) % 5);
}
Each philosopher,
before starting to eat,
must invoke the
operation pickup().
May result in the
suspension of the
philosopher thread.
19
test() Procedure
void test(int i) {
if ( (state[(i + 4) % 5] != eating) &&
(state[i] == hungry) &&
(state[(i + 1) % 5] != eating)) {
state[i] = eating;
self[i].signal();
}
}
Philosopher i can set the
variable state[i] = eating
only if her two neighbors
are not eating.
Release self[i] so that
the thread can proceed.
20
Solution to Dining Philosophers
• Philosopher i must invoke the operations pickup
and putdown in the following sequence:
dp.pickUp(i);
...
eat
...
dp.putDown(i);
• This solution ensures that no two neighbors are
eating simultaneously, and no deadlocks will occur.
• However, it is possible for a philosopher to starve
to death.
21
Implement monitor
using semaphore
• Variables
semaphore mutex; // (initially = 1)
semaphore next;
// (initially = 0)
int next_count = 0;
• Each external procedure F will be replaced by
wait(mutex);
…
body of F;
…
if (next_count > 0)
signal(next)
else
signal(mutex);
• Mutual exclusion within a monitor is ensured.
22
Implement monitor
using semaphore
• For each condition variable x, we have:
semaphore x_sem; // (initially = 0)
int x_count = 0;
• The operation x.wait can be implemented as:
x_count++;
if (next_count > 0)
signal(next);
else
signal(mutex);
wait(x_sem);
x_count--;
23
Implement monitor
using semaphore
• The operation x.signal can be implemented as:
if (x_count > 0) {
next_count++;
signal(x_sem);
wait(next);
next_count--;
}
24
Process-resumption order
• If several processes are suspended on condition x, and
an x.signal operation is executed by some process,
then how to determine which of the suspended
processes should be resumed next?
• Except FCFS, the conditional-wait construct can be
used:
x.wait(c)
where c is an integer expression that is evaluated
when the wait operation is executed.
• The value of c, called priority number, is then stored
with the name of the process that is suspended. When
x.signal is executed, the process with the smallest
associated priority number is resumed next.
25
Example
• Monitor controlling the allocationEach
of aprocess,
singlewhen
requesting an allocation of
resource among competing processes.
• monitor ResourceAllocation {
}
boolean busy;
condition x;
void acquire(int time) {
if (busy)
x.wait(time);
busy = true;
}
void release() {
busy = false;
x.signal();
}
void init() {
busy = false;
}
its resources, specifies the
maximum time it plans to
use the resource.
The monitor allocates
the resource to that
process that has the
shortest time-allocation
request.
26
Example
• A process that needs to access the resource must
following the sequence:
R.acquire(t);
...
access the resource;
...
R.release();
• Unfortunately, the monitor concept cannot
guarantee that the sequence will be followed.
access resource
processprocess
not releasing
process
notrequest same
without permission
releasing resource
requestedresource
resourcebefore release it
27
Access-control problem
• 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.
These checkings
are not reasonable
for large or
dynamic system.
Can be solved only by
additional mechanisms.
(chap18)
28
OS Synchronization
§ 7.8
Solaris 2:
• Implements a variety of locks to support
multitasking, multithreading (including real-time
threads), and multiprocessing.
• Synchronization in Solaris 2 Provides:
- adaptive mutex
- condition variables
- semaphores
- reader-writer locks
29
Adaptive Mutex
• An adaptive mutex protects access to every critical
data item. It starts as a standard semaphore
implemented as a spinlock. The thread holding the
data is likely to end
• If the data are locked (in use), the adaptive
mutex
soon.
Put to sleep for avoiding the
does one of two things:
spinning when the lock will
– If the lock is held by a thread that is currently running
not be freed reasonably
on another CPU, the thread spins while waiting for the
quickly.
lock to become available.
– If the thread holding the lock is not currently in run
state, the thread blocks and go to sleep until the lock
being released.
30
Adaptive Mutex
Multiple
Choices
Question:
• An adaptive
mutex
protects access to every critical
item. It operations
starts as a standard
semaphore
( data
) Different
may be adopted
by the
implemented
as a mechanism
spinlock. when a thread is
adaptive mutex
locked (in
data.
Thethe
decision
is mutex
• If requesting
the data area locked
use),
adaptive
Put to sleep for avoiding the
made
of
does
onebyofthe
twostatus
things:
spinningCPU
when speed
the lcok will
(a)
located
memories
(b)
relative
– If the lock is held by a thread that is currently running
not be
(c)
thread
holding
thespins
lock
(d)freed
the reasonably
type
on the
another
CPU,
the thread
while
waiting
for the
quickly.
to become
available.
oflock
monitor
entries
– If the thread holding the lock is not currently in run
Answer:
C
state, the thread
blocks and go to sleep until the lock
being released.
31
Adaptive Mutex
• Adaptive mutex only protect those data that are
accessed by short code segments where a lock will
be held for less than a few hundred instructions.
• For longer code segments, condition variables and
semaphores are used.
If the code segment is
– If the desired lock is already held,
thethan
thread
issues
longer
that,
spina
wait and sleep.
waiting will be
inefficient.
– The cost of putting a thread toexceedingly
sleep and waking
it is
less than the cost of wasting several hundred
instructions waiting in a spinlock.
32
Readers-Writers Lock
• The readers-writers locks are used to protect
data that are accessed frequently, but
usually only in a read-only manner.
• In these circumstances, readers-writers
locks are more efficient than semaphores.
THINK
• Expensive to implement, so again they are
used on only long sections of code.
33
OS Synchronization
Windows 2000:
• Uses interrupt masks to protect access to global resources
on uniprocessor systems.
• Uses spinlocks on multiprocessor systems.
• Also provides dispatcher objects which may act as either
mutexes and semaphores.
• Dispatcher objects may also provide events. An event acts
much like a condition variable.
34
Atomic Transactions
§ 7.9
• Need to make sure that a CS forms a single logical
unit of work that either is performed in its entirety
or is not performed at all.
• A collection of instructions (or operations) that
performs a single logical function is called a
transaction.
• A major issue in processing transactions is the
preservation of atomicity despite the possibility of
failures within the computer system.
35
Commit & Abort
• From our point of view, a transaction is
simply a sequence of read and write
operations, terminated by commit or abort
operation.
–commit: signifies that the transaction has
terminated successfully.
–abort: the transaction had to cease its normal
execution due to some logical error.
36
Roll Back
• An aborted transaction must have no effect
on the state of the data that it has already
modified, so that the atomicity property is
ensured.
• Thus, the state of the data accessed by an
aborted transaction must be restored to what
it was just before the transaction started
executing --- rolled back.
37
Device Properties (Skip)
•
1.
To determine how the system should ensure atomicity,
we need first to identify the properties of devices used
for storing the various data accessed by the transactions.
Volatile Storage
Information residing involatile storage does not usually survive system
crashed.
2. Nonvolatile Storage
Information residing involatile storage usually survive system crashed.
3. Stable Storage
Information residing is never lost.
38
Mechanisms for ensuring
Transaction Atomicity
• Log-Based Recovery
• Checkpoints
• Concurrent Atomic Transactions
39
Log-Based Recovery
§ 7.9.2
• Record informatin describing all the modifications
made by the transaction to the various data it
accessed.
• Write-ahead logging:
Each log record describes a single operation of a
transaction write.
Fields:
–
–
–
–
Transaction Name
Data Item Name
Old Value
New Value
40
Log-Based Recovery
• Before a transaction Ti starts its execution,
record <Ti starts> is written to the log.
• During its execution, any write operation
by Ti is preceded by the writing of the
appropriate new record to the log.
• When Ti commits, the record < Ti commits>
is written to the log.
41
Log-Based Recovery
• Performance penalty ... two physical writes
are required for every logical write requested.
• More storage is needed: for the data and the
log.
• The recovery algorithm uses two procedures:
– undo(Ti)
– redo(Ti)
42
Log-Based Recovery
• If a transaction Ti aborts → restore the state of the
data that it has updated by executing undo(Ti).
• If a system failure occurs, must consulting the log
to determine the proper operation:
– The log contains < Ti starts> record, but does not
contain < Ti commits> record → Transaction Ti needs to
be undone.
– The log contains both the < Ti starts> and the < Ti
commits> records → Transaction Ti needs to be redone.
– Drawbacks ...
43
Log-Based Recovery
• Drawbacks:
1. The search process takes time.
2. Most of the transactions need to be redone
already updated the data. Redoing the
modificaiton takes longer.
• To reduce the overhead ... use
“Checkpoints.”
44
Checkpoints
§ 7.9.3
• In addition to the write-ahead log, the
system periodically performs checkpoints
that require:
– Output all log records currently residing in
main memory onto stable storage.
– Output all modified data residing in main
memory to the stable storage.
– Output a log record <checkpoint> onto stable
storage.
allows the system to
streamline its recovery
procedure
45
Checkpoints
• After failure occur, the recovery routine examines
the log to determine the most recent transaction Ti
that started before the most recent chekckpoint.
• The redo and undo need to be applied to only Ti
and all Tj that started execution after Ti:
T
– For all Tk in T such that record <Tk commits> appears
in the log, execute redo(Tk).
– For all Tk in T that have no <Tk commits> record in the
log, execute undo(Tk).
46
Concurrent Atomic Transactions
• Serializability can be maintained by simply
executing each transaction within a CS ...
too restrictive.
• We can allow transactions to overlap their
execution, while maintaining serializability
... concurrency-control algorithms
47
Serial Schedule
• Schedule 1:
• A schedule where each
transaction is executed
atomically is called a serial
schedule.
• For a set of n transactions,
there exist n! different valid
serial schedules.
• Each serial schedule is
correct.
T0
§ 7.9.4.1
T1
read(A)
write(A)
read(B)
write(B)
read(A)
write(A)
read(B)
write(B)
48
Nonserial Schedule
• If two transactions are allowed to overlap
their execution... nonserial schedule.
• A nonserial schedule does not necessarily
incorrect.
49
Nonserial Schedule
• Two consective operation O1 and O2 of Ti
and Tj are conflict if they access the same
data item and at least one of these
operations is a write operation.
T0
T1
• Schedule 2:
read(A)
write(A)
read(A)
write(A)
read(B)
write(B)
read(B)
write(B)
50
Nonserial Schedule
• Two consective operation O1 and O2 of Ti
and Tj are conflict if they access the same
data item and at least one of these
operations is a write operation.
T0
T1
• Schedule 2:
conflict
read(A)
write(A)
read(A)
write(A)
read(B)
write(B)
read(B)
write(B)
51
Nonserial Schedule
• Two consective operation O1 and O2 of Ti
and Tj are conflict if they access the same
data item and at least one of these
operations is a write operation.
T0
T1
• Schedule 2:
read(A)
write(A)
not conflict
read(A)
write(A)
read(B)
write(B)
read(B)
write(B)
52
Nonserial Schedule
• If Oi and Oj are consective and do not
conflict, then Oi and Oj can be swapped to
produce a new but equivalent schedule.
T0
• Schedule 2:
T1
read(A)
write(A)
not conflict
read(A)
write(A)
read(B)
write(B)
read(B)
write(B)
53
Nonserial Schedule
• If Oi and Oj are consective and do not
conflict, then Oi and Oj can be swapped to
produce a new but equivalent schedule.
• Schedule 2:
T0
T1
read(A)
write(A)
read(A)
read(B)
write(A)
write(B)
read(B)
write(B)
54
Nonserial Schedule
• If Oi and Oj are consective and do not
conflict, then Oi and Oj can be swapped to
produce a new but equivalent schedule.
• Schedule 2:
T0
T1
read(A)
write(A)
read(B)
read(A)
write(A)
write(B)
read(B)
write(B)
55
Nonserial Schedule
• If Oi and Oj are consective and do not
conflict, then Oi and Oj can be swapped to
produce a new but equivalent schedule.
• Schedule 2:
T0
T1
read(A)
write(A)
read(B)
read(A)
write(B)
write(A)
read(B)
write(B)
56
Nonserial Schedule
• If Oi and Oj are consective and do not
conflict, then Oi and Oj can be swapped to
produce a new but equivalent schedule.
• Schedule 2:
• This schedule is
conflict serializable.
T0
T1
read(A)
write(A)
read(B)
write(B)
read(A)
write(A)
read(B)
write(B)
57
Locking Protocol
• Locking protocol governs how locks are
acquired and released by transactions.
• Modes in which a data item can be locked:
– Shared: If a transaction Ti has obtained a
shared-mode lock (denoted by S) on data item
Q, then Ti can read this item, but cannot write Q.
– Exclusive: If a transaction Ti has obtained an
exclusive-mode lock (denoted by X) on data
item Q, then Ti can both read and write Q.
Similar to the reader-writers
algorithm
58
Locking protocol
• It is not always desirable for a transaction to unlock a data
item immediately after its last access of that data item,
because serializability may bot be ensured.
• One protocol ensures serializability is the two-phase
locking protocol: each transaction issue lock and unlock
in two phases:
– Growing Phase: A transaction may obtain locks, but may not
release any lock.
– Shrinking Phase: A transaction
release locks, but may not
Ensures may
conflict
obtain any new locks.
serializability. However, it
• Initially, a transaction is in the growing phase and acquires
does the
nottransaction
ensure freedom
locks as needed. Once
releases a lock, it
fromand
deadlock.
enters the shrinking phase,
no more lock requests can
be issed.
59
Timestamp-based Protocols
• The serializability order among transactions
can be selected in advance:
– Unique fixed timestamp TS(Ti) for each Ti
assigned by the system before Ti starts.
– TS(Ti) < TS(Tj) for later transaction Tj.
• Value of the system clock or a logical
counter can be used to implement the
timestamp.
60
Timestamp-based Protocols
• The timestamps of the transactions determine the
serializability order.
If TS(Ti) < TS(Tj), then the system must ensure that the
produced schedule is equivalent to a serial schedule in
which transaction Ti appears before transaction Tj.
• Each data item Q has two timestamp value:
– W-timestamp(Q): the largest timestamp of any
transaction that executed write(Q) successfully.
– R-timestamp(Q): the largest timestamp of any
transaction that executed
(Q) successfully.
Updatedread
whenever
a new
read(Q) or write(Q)
instruction is executed.
61
Timestamp-based Protocols
• This protocol ensures that any conflicting read and write operations are
executed in timestamp order.
• Suppose Ti issues read(Q):
– If TS(Ti) < W-timestamp(Q) → Ti needs to read a value of Q that was
already overwritten. read operation is rejected and Ti is rolled back.
– If TS(Ti) ≥ W-timestamp(Q) → read operation is executed, and Rtimestamp(Q) is set to the maximum of R-timestamp(Q) and TS(Ti).
• Suppose Ti issues write(Q):
– If TS(Ti) < R-timestamp(Q) → the value of Q that Ti is producing was
needed previously and Ti assumed that this value would never be
produced. write operation is rejected, and Ti is rolled back.
– If TS(Ti) < W-timestamp(Q) → Ti is attempting to write an absolete value
of Q. write operation is rejected and Ti is rolled back.
– Otherwise, the write operation is executed.
• A transaction Ti, that is rolled back by the concurrency-control scheme
as a result of the issuing of either a read or write operation is
assigned a new timestamp and is restarted.
62
Timestamp-based Protocols
• This protocol ensures that any conflicting read and write operations are
executed in timestamp order.
• Suppose Ti issues read(Q):
– If TS(Ti) < W-timestamp(Q) → Ti needs to read a value of Q that was
already overwritten. read operation is rejected and Ti is rolled back.
– If TS(Ti) ≥ W-timestamp(Q) → read operation is executed, and Rtimestamp(Q) is set to the maximum of R-timestamp(Q) and TS(Ti).
• Suppose Ti issues write(Q):
– If TS(Ti) < R-timestamp(Q) → the value of Q that Ti is producing was
W-timestamp(Q)
needed previously and Ti assumed that this
value would never be
T
produced. write operation
1 is rejected, and Ti is rolled back.
TS(Ti)
– If TS(Ti) < W-timestamp(Q)
→ Ti is attempting to write an absolete value
of Q. write operation is rejected and Ti is rolled back.
W-timestamp(Q)
– Otherwise, the write operation is executed.
• A transaction Ti, that is rolled
back by the concurrency-control scheme
read(Q)
as a result of the issuing of either a read or write operation is
assigned a new timestamp and is restarted.
63
Timestamp-basedT Protocols
1
• This protocol ensures that anyTS(Ti)
conflicting read and write operations are
executed in timestamp order.
W-timestamp(Q)
R-timestamp(Q)
• Suppose Ti issues read(Q):
– If TS(Ti) < W-timestamp(Q) → Ti needs
to read a value of Q that was
write(Q)
already overwritten. read operation is rejected and Ti is rolled back.
– If TS(Ti) ≥ W-timestamp(Q) → read operation is executed, and Rtimestamp(Q) is set to the maximum of R-timestamp(Q) and TS(Ti).
• Suppose Ti issues write(Q):
– If TS(Ti) < R-timestamp(Q) → the value of Q that Ti is producing was
needed previously and Ti assumed that this value would never be
produced. write operation is rejected, and Ti is rolled back.
– If TS(Ti) < W-timestamp(Q) → Ti is attempting to write an absolete value
of Q. write operation is rejected and Ti is rolled back.
– Otherwise, the write operation is executed.
• A transaction Ti, that is rolled back by the concurrency-control scheme
as a result of the issuing of either a read or write operation is
assigned a new timestamp and is restarted.
64
Example
• Assume a transaction is
assigned a timestamp
immediately before its first
instruction.
• TS(T2) < TS(T3)
• Possible under timestamp
protocol
• Also can be produced by twophase locking protocol.
T2
T3
read(B)
read(B)
write(B)
read(A)
read(A)
write(A)
65
Timestamp-based Protocols
• Some schedules are possible under two-phase
locking protocol but not under the timestamp
protocol, and vice versa.
• The timestamp-ordering protocol ensures conflict
serializability. It follows from the fact that
conflicting operations are processed in timestamp
order.
• Ensures freedom from deadlock, because no
transaction ever waits.
66
The End
67