Automatically Identifying Critical Input and Code Regions ...
Critical Regions
67
1 Critical Regions • 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: § 7.6 signal(mutex); critical section wait(mutex); Several processes may be executing in their critical section simultaneously. wait(mutex); critical section wait(mutex); A deadlock will occur. A process omits the wait(mutex), or the signal(mutex), or both Either mutual exclusion is violated or a deadlock will occur.
description
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) , or the signal(mutex) , or both - PowerPoint PPT Presentation
Transcript of Critical Regions
1
Critical Regions• 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:
§ 7.6
signal(mutex);critical sectionwait(mutex);
Several processes may be executing in their critical section simultaneously.
signal(mutex);critical sectionwait(mutex);
Several processes may be executing in their critical section simultaneously.
wait(mutex);critical sectionwait(mutex);
A deadlock will occur.
wait(mutex);critical sectionwait(mutex);
A deadlock will occur.
A process omits the wait(mutex), or the signal(mutex), or both
Either mutual exclusion is violated or a deadlock will occur.
A process omits the wait(mutex), or the signal(mutex), or both
Either mutual exclusion is violated or a deadlock will occur.
2
Critical Regions• 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:
§ 7.6
signal(mutex);critical sectionwait(mutex);
Several processes may be executing in their critical section simultaneously.
signal(mutex);critical sectionwait(mutex);
Several processes may be executing in their critical section simultaneously.
wait(mutex);critical sectionwait(mutex);
A deadlock will occur.
wait(mutex);critical sectionwait(mutex);
A deadlock will occur.
A process omits the wait(mutex), or the signal(mutex), or both
Either mutual exclusion is violated or a deadlock will occur.
A process omits the wait(mutex), or the signal(mutex), or both
Either mutual exclusion is violated or a deadlock will occur.
Multiple Choices Question:( ) What kind of problem can happen if
more than one thread work on a semaphore in the following sequence? signal(mutex);
criticalSection(); wait(mutex);
(a) starvation (b) deadlock (c) blocking (d) not synchronizing (e) violate mutual exclusion
Answer: e
3
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.
4
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.
5
Critical Region
• Example: two statementsregion 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.”
6
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.
7
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++;
}
8
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--;}
9
Implement the conditional critical region (Skip)
10
• High-level synchronization construct that allows the safe sharing of an abstract data type among concurrent processes.
• A monitor presents a set of programmer-defined 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.
Monitors § 7.7
11
monitor monitor-name{
shared variable declarationsprocedure body P1 (…) {
. . .}procedure body P2 (…) {
. . .} procedure body Pn (…) {
. . .} {
initialization code}
}
Monitor Syntax
12
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
13
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
True-False Question:
( ) Although there maybe several processes inside the monitor at the same time, there can only be one process with the state of active at a time.
Answer: ○
14
Schematic View of a Monitor
15
Condition Variables
• 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.
Contrast this operation with the signal operation
associated with semaphores, which always affects the state of the semaphore.
16
Monitor with condition variables
17
Two Possibilities
• When x.signal() operation is invoked by a process P, there is a suspended process Q 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, or waits for another condition.
• Concurrent C: when process P executes the signal operation, process Q is immediately resumed.
Advocated by Hoare
More reasonable
since P was already executing in the
monitor.
“logical” condition for
which Q was waiting may no longer hold by
the time Q is resumed.
18
Solution to Dining Philosophers
monitor dp {
enum {thinking, hungry, eating} state[5];condition self[5];void pickup(int i) // following slidesvoid putdown(int i) // following slidesvoid test(int i) // following slidesvoid init() {
for (int i = 0; i < 5; i++)state[i] = thinking;
}}
philosopher i can delay herself when she is hungry, but is unable to obtain the chopsticks she
needs.
19
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 neighborstest((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.
20
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();
}}
Release self[i] so that the thread can proceed.
Philosopher i can set the variable state[i] = eating only if her two neighbors
are not eating.
21
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.
22
Implement monitorusing semaphore
• Variables semaphore mutex; // (initially = 1)semaphore next; // (initially = 0)int next_count = 0;
• Each external procedure F will be replaced bywait(mutex); … body of F; …if (next_count > 0)
signal(next)else
signal(mutex);
• Mutual exclusion within a monitor is ensured.
23
Implement monitorusing 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--;
24
Implement monitorusing semaphore
• The operation x.signal can be implemented as:
if (x_count > 0) {next_count++;signal(x_sem);wait(next);next_count--;
}
25
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.
26
Example
• Monitor controlling the allocation of a single 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;}
}
Each process, when requesting an allocation of 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.
27
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 without permission
process not releasing resource
process releasing not requested resource
process request same resource before release it
28
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)
29
OS Synchronization
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
§ 7.8
30
Adaptive Mutex
• An adaptive mutex protects access to every critical data item. It starts as a standard semaphore implemented as a spinlock.
• If the data are locked (in use), the adaptive mutex does one of two things:– If the lock is held by a thread that is currently running
on another CPU, the thread spins while waiting for the 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.
The thread holding the data is likely to
end soon.Put to sleep for avoiding the spinning when the lock
will not be freed reasonably quickly.
31
Adaptive Mutex
• An adaptive mutex protects access to every critical data item. It starts as a standard semaphore implemented as a spinlock.
• If the data are locked (in use), the adaptive mutex does one of two things:– If the lock is held by a thread that is currently running
on another CPU, the thread spins while waiting for the 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.
Put to sleep for avoiding the spinning when the lcok
will not be freed reasonably quickly.
Multiple Choices Question:( ) Different operations may be adopted by the
adaptive mutex mechanism when a thread is requesting a locked data. The decision is made by the status of(a) located memories (b) relative CPU speed (c) the thread holding the lock (d) the type of monitor entries
Answer: C
32
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 desired lock is already held, the thread issues a
wait and sleep.
– The cost of putting a thread to sleep and waking it is less than the cost of wasting several hundred instructions waiting in a spinlock.
If the code segment is longer than that, spin
waiting will be exceedingly inefficient.
33
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.
• Expensive to implement, so again they are used on only long sections of code.
THINKTHINK
34
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.
35
Atomic Transactions
• 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.
§ 7.9
36
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.
37
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.
38
Device Properties (Skip)
• 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.
1. Volatile StorageInformation residing involatile storage does not usually survive system crashed.
2. Nonvolatile StorageInformation residing involatile storage usually survive system crashed.
3. Stable StorageInformation residing is never lost.
39
Mechanisms for ensuringTransaction Atomicity
• Log-Based Recovery
• Checkpoints
• Concurrent Atomic Transactions
40
Log-Based Recovery• 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
§ 7.9.2
41
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.
42
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)
43
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 ...
44
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.”
45
Checkpoints
• 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.
§ 7.9.3
allows the system to streamline its
recovery procedure
46
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:
– 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).
T
47
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
48
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.
§ 7.9.4.1
T0 T1
read(A)write(A)read(B)write(B) read(A) write(A) read(B) write(B)
49
Nonserial Schedule
• If two transactions are allowed to overlap their execution... nonserial schedule.
• A nonserial schedule does not necessarily incorrect.
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.
• Schedule 2: T0 T1
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.
• Schedule 2: T0 T1
read(A)write(A) read(A) write(A)read(B)write(B) read(B) write(B)
conflict
52
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.
• Schedule 2: T0 T1
read(A)write(A) read(A) write(A)read(B)write(B) read(B) write(B)
not conflict
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) write(A)read(B)write(B) read(B) write(B)
not conflict
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(A)read(B) 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(A)write(B) 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: T0 T1
read(A)write(A)read(B) read(A)write(B) write(A) read(B) write(B)
57
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)
58
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
59
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 may release locks, but may not
obtain any new locks.
• Initially, a transaction is in the growing phase and acquires locks as needed. Once the transaction releases a lock, it enters the shrinking phase, and no more lock requests can be issed.
Ensures conflict serializability. However, it does not ensure freedom
from deadlock.
60
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.
61
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 read(Q) successfully.Updated whenever a new
read(Q) or write(Q) instruction is executed.
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 R-timestamp(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.
63
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 R-timestamp(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.
T1
read(Q)
W-timestamp(Q)
TS(Ti)
W-timestamp(Q)
64
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 R-timestamp(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.
T1
write(Q)
R-timestamp(Q)
TS(Ti)
W-timestamp(Q)
65
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 two-
phase locking protocol.
T2 T3
read(B) read(B) write(B)read(A) read(A) write(A)
66
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.
67
The End
