OPERATING SYSTEM CONCEPTS 操作系统概念 东南大学计算机学院. Baili Zhang/ Southeast Process synchronization

Transcription

1 OPERATING SYSTEM CONCEPTS 操作系统概念 东南大学计算机学院 Baili Zhang/ Southeast 1 6. Process synchronization Objectives To introduce the critical-section problem, whose solutions can be used to ensure the consistency of shared data To present both software and hardware solutions of the critical-section problem To introduce the concept of an atomic transaction and describe mechanisms to ensure atomicity Baili Zhang/ Southeast 2 1

2 6. Process synchronization 6.1 Background 6.2 The Critical-Section Problem 6.3 Peterson s Solution 6.4 Synchronization Hardware 6.5 Semaphores 6.6 Classic Problems of Synchronization 6.7 Monitors 6.8 Synchronization Examples 6.9 Atomic Transactions Baili Zhang/ Southeast Background Concurrent access to shared data may result in data inconsistency A example: bounded buffer problem with shared data Producer while (true) { /* produce an item in nextproduced */ while (counter == BUFFER_SIZE); // do nothing buffer [in] = nextproduced; in = (in + 1) % BUFFER_SIZE; counter++; } Baili Zhang/ Southeast 4 2

3 Consumer 6.1 Background while (true) { while (count == 0); // do nothing nextconsumed = buffer[out]; out = (out + 1) % BUFFER_SIZE; count--; /* consume the item in nextconsumed*/ } The statements /* count=5 */ counter++; //Producer counter--; // Consumer Baili Zhang/ Southeast Background count++ could be implemented as register1 = count register1 = register1 + 1 count = register1 count-- could be implemented as register2 = count register2 = register2-1 count = register2 Remember that the contents of the register will be saved and restored by the interrupt Baili Zhang/ Southeast 6 3

4 6.1 Background If both the producer and consumer attempt to update the buffer concurrently, the assembly language statements may get interleaved One such interleaving is T0: producer execute register1 = counter {register1 = 5} T1: producer execute register1 = register1 + 1 {register1 = 6} T2: consumer execute register2 = counter {register2 = 5} T3: consumer execute register2 = register2-1 {register2 = 4} T4: producer execute counter = register1 {counter = 6 } T5: consumer execute counter = register2 {counter = 4} The value of count may be either 4 or 6, where the correct result should be 5 Baili Zhang/ Southeast Background Race condition The situation where several processes access and manipulate shared data concurrently. The final value of the shared data depends upon which process finishes last. Synchronized Concurrent process must be synchronized To prevent race conditions and maintain data consistency requires mechanisms to ensure the orderly execution of cooperating processes Baili Zhang/ Southeast 8 4

5 6. Process synchronization 6.1 Background 6.2 The Critical-Section Problem 6.3 Peterson s Solution 6.4 Synchronization Hardware 6.5 Semaphores 6.6 Classic Problems of Synchronization 6.7 Monitors 6.8 Synchronization Examples 6.9 Atomic Transactions Baili Zhang/ Southeast The Critical-Section Problem Critical section The n processes compete to use some shared data Changing common variables updating a table writing a file Each process has a code segment, called critical section, in which the shared data is accessed Baili Zhang/ Southeast 10 5

6 6.2 The Critical-Section Problem The critical section problem Be how to design a protocol that One process is executing in its critical section, no other process is to be allowed to execute in its critical section of accessing the same shared data No two process are executing in their critical section at the same time Baili Zhang/ Southeast The Critical-Section Problem To solve the critical-section problem Criteria for the critical section problem solution Mutual Exclusion( 互斥 ) If process P i is executing in its critical section, then no other processes can be executing in their critical sections. Progress( 空闲让进 ) If no process is executing in its critical section and there exist some processes that wish to enter their critical section The selection of the processes that will enter the critical section next cannot be postponed indefinitely. Baili Zhang/ Southeast 12 6

7 6.2 The Critical-Section Problem Bounded Waiting( 有限等待 ) A bound must exist on the number of times for the processes waiting for entering their critical sections General structure of process P i do { entry section critical section exit section remainder section } while (1); Baili Zhang/ Southeast The Critical-Section Problem The critical sections in operating systems Race conditions in operating systems At a time, many kernel-mode processes/threads may be active in the operating system The code implementing an OS kernel code is subject to several possible race conditions It is up to kernel developers to ensure that OS is free from such race conditions Baili Zhang/ Southeast 14 7

8 6.2 The Critical-Section Problem Two approaches to handle critical sections in OS Non-preemptive kernels A kernel-mode process will run until it exits kernel mode, or blocks. It is essentially free from race conditions on kernel data structures, as only one process is active in the kernel at a time Windows XP/2000 Traditional UNIX Linux (prior to 2.6) Baili Zhang/ Southeast The Critical-Section Problem Preemptive kernels Be carefully designed to ensure that shared kernel data are free from race conditions Be especially difficult to design for SMP Solaris IRIX Linux (2.6 or later) The advantage of preemptive kernels Be more suitable for real-time programming May be more responsive, since there is less risk that a kernel-mode process will run for an arbitrarily long period Baili Zhang/ Southeast 16 8

9 6. Process synchronization 6.1 Background 6.2 The Critical-Section Problem 6.3 Peterson s Solution 6.4 Synchronization Hardware 6.5 Semaphores 6.6 Classic Problems of Synchronization 6.7 Monitors 6.8 Synchronization Examples 6.9 Atomic Transactions Baili Zhang/ Southeast Peterson s Solution Software-based solution to the critical section problem conditions Only 2 processes, P 0 and P 1 Assume that the LOAD and STORE instructions are atomic; that is, cannot be interrupted The two processes share two variables: int turn; // =0 or 1 indicates whose turn it is to enter the critical section Boolean flag[2]; is used to indicate if a process is ready to enter the critical section flag[i] = true implies that process P i is ready! Baili Zhang/ Southeast 18 9

10 6.3 Peterson s Solution Algorithm 1 Process P i do { while (turn!= i) ; critical section turn = j; //load and store reminder section } while (true); Satisfies mutual exclusion, but not progress requirement Turn=0, and P1 is ready to enter again(after entering) P1 will wait for ever Requires that P0 and P1 must run in turn Baili Zhang/ Southeast Peterson s Solution Algorithm 2 Process P i do { flag [i] = true; while (flag [j]==true) ; critical section flag [i] = false; remainder section } while (true); Satisfies mutual exclusion, but not progress requirement flag [i]= flag [j]=true; P0, P1 will all wait for ever Baili Zhang/ Southeast 20 10

11 6.3 Peterson s Solution Algorithm 3 (Peterson 1981) Process P i do { flag [i] = true; turn = j; while (flag [j]==true && turn == j) ; critical section flag [i] = false; remainder section } while (ture); Baili Zhang/ Southeast Peterson s Solution Process P j do { flag [j] = true; turn = i; while (flag [i]==true && turn == i) ; critical section flag [j] = false; remainder section } while (ture); Meets all three requirements; solves the critical-section problem for two processes. Baili Zhang/ Southeast 22 11

12 6. Process synchronization Question Block in critical-section? Interrupt / process scheduling in criticalsection? Baili Zhang/ Southeast Process synchronization 6.1 Background 6.2 The Critical-Section Problem 6.3 Peterson s Solution 6.4 Synchronization Hardware 6.5 Semaphores 6.6 Classic Problems of Synchronization 6.7 Monitors 6.8 Synchronization Examples 6.9 Atomic Transactions Baili Zhang/ Southeast 24 12

13 6.4 Synchronization Hardware Lock (essential solution model) A process must acquire a lock before entering a critical section It releases the lock when it exits the critical section do { acquire lock critical section release lock remainder section } while (TRUE); The design of such locks can be quite sophisticated( 需要丰富的经验 ) Baili Zhang/ Southeast Synchronization Hardware Disabling interrupts while a shared variable was being modified Can be applied to Uni-processor Non-preemptive kernel takes this approach Not feasible for Multi-processors Disabling interrupts can be time consuming, as the message is passed to all the processors The message passing delays entry into each critical section, and system efficiency decreases The effect on a system s clock,if the clock is kept updated by interrupts Baili Zhang/ Southeast 26 13

14 6.4 Synchronization Hardware Special atom instruction TestAndSet() Test and modify the content of a word atomically boolean TestAndSet (boolean lock) { boolean rv = lock; lock = TRUE; return rv: } // 将 lock 置为 true 并返还原先 lock 值 Baili Zhang/ Southeast Synchronization Hardware Process P i do { while (TestAndSet(lock)) ; critical section lock = false; remainder section } If two TestAndSet() are executed simultaneously each on a different CPU, they will be run sequentially in some arbitrary order Baili Zhang/ Southeast 28 14

15 6.4 Synchronization Hardware Swap() Swap two variables atomically void Swap(boolean &a, boolean &b) { boolean temp = a; a = b; b = temp; } Baili Zhang/ Southeast Synchronization Hardware Process P i do { key = true; while (key == true) Swap(lock,key); critical section lock = false; remainder section } Satisfies mutual exclusion, but not the boundedwaiting requirement If there are many processes waiting for entering, Pi may be blocked in TestAndSet() or Swap() without limit Baili Zhang/ Southeast 30 15

16 6.4 Synchronization Hardware Bounded-waiting with TestAndSet() do{ waiting[i] = true; key = true; while (waiting[i]==true && key==true) key = TestAndSet(lock) ; waiting[i] = false; //key=false critical section j = (i+1)%n; // 寻找下一个 waiting[]=true while ((j!= i) && waiting[j]==false ) j = (j+1) % n; if (j==i) lock = false; // 没有 waiting[]=true else waiting[j] = false; // waiting[]=true 改为 false remainder section // 阻塞于 TestAndSet 地 pj } while (true); // 可以直接进入临界区 Baili Zhang/ Southeast Synchronization Hardware Mutual exclusion: Process Pi can enter its critical section only either waiting[i] == false or key == false. key == false: the first process to execute the TestAndSet. waiting[i] == false: only if another process leaves its critical section. Progress requirement and bounded-waiting requirement: When a process leaves its critical section, it scans the array waiting in the cyclic ordering. It designates the first process in this ordering that is in the entry section as the next one to enter the critical section. Baili Zhang/ Southeast 32 16

17 6. Process synchronization 6.1 Background 6.2 The Critical-Section Problem 6.3 Peterson s Solution 6.4 Synchronization Hardware 6.5 Semaphores 6.6 Classic Problems of Synchronization 6.7 Monitors 6.8 Synchronization Examples 6.9 Atomic Transactions Baili Zhang/ Southeast 33 Semaphore 6.5 Semaphores Be less complicated than hardware-based solution to the critical-section problem can be viewed as an object which has an integer value and two atomic operations A Semaphore S integer variable may be initialized via a nonnegative value Can only be accessed via two indivisible (atomic) operations: P() and V() P(): the wait() operation decrements the semaphore value If the value becomes negative, then the process executing the wait() is blocked. Baili Zhang/ Southeast 34 17

18 6.5 Semaphores wait (S) { while (S <= 0) ; // no-op S--; } V(): The signal() operation increments the semaphore value If the value is not positive, then a process blocked by a wait() operation is unblocked signal (S) { S++; } The wait() and signal() must be executed indivisibly(atomically) Baili Zhang/ Southeast Semaphores Usage Binary semaphore integer value can range only between 0 and 1 can be simpler to implement, and to deal with the criticalsection problem Also known as mutex locks Can use a counting semaphore S as a binary semaphore S=0 or 1 Counting semaphore integer value can range over an unrestricted domain Can be used to control access to a given resource consisting of a finite number of instances Baili Zhang/ Southeast 36 18

19 6.5 Semaphores S2 must be executed after S1 has completed Semaphore synch; // initialized to 0 P i S1 signal(synch) P j wait(synch) S2 Provides mutual exclusion Semaphore mutex; // initialized to 1 do { wait (mutex); Critical Section signal (mutex); remainder section } while (TRUE); Example: Classic Problems of Synchronization P48 Baili Zhang/ Southeast 37 Implementation busy waiting 6.5 Semaphores While a process is in its critical section, any other process that tries to enter its critical section must loop continuously in the entry code Busy waiting wastes the CPU cycles that can be used by other processes productively Spinlock The process spins, while waiting for the lock Baili Zhang/ Southeast 38 19

20 6.5 Semaphores The advantage of spinlock to the multiprocessor system No context switch is required when a process must wait on a lock A context switch may take considerable time If locks are expected to be held for short times, the spinlocks are useful One thread can spin on one processor while another thread performs its critical section on another processor Baili Zhang/ Southeast Semaphores The problem of spinlock to uni-processor system A single CPU is shared among many process spinlock wastes the CPU cycles that can be used by other processes Solution: modify the definition of the wait() and signal() Wait(): the process can block() itself rather than engaging in busy waiting Signal(): change the blocking process from the waiting state to the ready state Baili Zhang/ Southeast 40 20

21 6.5 Semaphores Assume two simple operations: block() suspends the process that invokes it. wakeup(p) resumes the execution of a blocked process P Define a semaphore as a record typedef struct { int value; struct process *L; } semaphore; Baili Zhang/ Southeast Semaphores Semaphore operations now defined as wait(s): S.value--; if (S.value < 0) { add this process to S.L; block; } signal(s): S.value++; // 完成, 释放一个信号量 if (S.value <= 0) { // 队列中有排队的 remove a process P from S.L; wakeup(p); } Baili Zhang/ Southeast 42 21

22 6.5 Semaphores wait () and signal () must be executed atomically Two methods Disable interrupt Simply inhibiting interrupts during the time the wait() and signal() operations are executing Critical section problem Must guarantee that no two processes can execute wait () and signal () on the same semaphore at the same time Baili Zhang/ Southeast Semaphores In a single-processor environment Disable interrupt In a multi-processor environment Instructions from different processes running on different processors may be interleaved in some arbitrary way Disable interrupt is inefficient Critical section can be applied SMP system must provide alternative locking techniques Hardware-based solution Software-based solution + spinlock (the critical section includes the codes of wait() and signal() ) Baili Zhang/ Southeast 44 22

23 6.5 Semaphores Note that we have not completely eliminated busy waiting with definition of wait() and signal() 1)Busy waiting has been removed from the entry section of application programs applications may spend lots of time in critical sections Busy waiting is extremely inefficient 2)Busy waiting is used to the critical section of executing the wait() and signal() in multi-processor environment implementation code is very short (less than ten instructions) the critical section is rarely occupied ( 处于临界区的时间很短 ),and busy waiting occurs rarely Baili Zhang/ Southeast Semaphores 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 P 0 P 1 wait (S); wait (Q); wait (Q); wait (S); signal (S); signal (Q); signal (Q); signal (S); Baili Zhang/ Southeast 46 23

24 Starvation 6.5 Semaphores indefinite blocking A process may never be removed from the semaphore queue in which it is suspended LIFO:last-in, first-out Priority Inversion - Scheduling problem when lower-priority process holds a lock needed by higher-priority process Baili Zhang/ Southeast Process synchronization 6.1 Background 6.2 The Critical-Section Problem 6.3 Peterson s Solution 6.4 Synchronization Hardware 6.5 Semaphores 6.6 Classic Problems of Synchronization 6.7 Monitors 6.8 Synchronization Examples 6.9 Atomic Transactions Baili Zhang/ Southeast 48 24

25 6.6 Classic Problems of Synchronization Bounded-Buffer Problem( 生产者 - 消费者问题 / 有限缓存问题 ) N buffers, each can hold one item Semaphore mutex initialized to the value 1 Semaphore full initialized to the value 0 Semaphore empty initialized to the value N Baili Zhang/ Southeast Classic Problems of Synchronization The structure of the producer process(es) do { // produce an item in nextp wait (empty); wait (mutex); // Critical Section //add the item to the buffer signal (mutex); signal (full); } while (TRUE); Baili Zhang/ Southeast 50 25

26 6.6 Classic Problems of Synchronization The structure of the consumer process(es) do { wait (full); wait (mutex); // Critical Section // remove an item from buffer signal (mutex); signal (empty); // consume the item in nextc } while (TRUE); Baili Zhang/ Southeast Classic Problems of Synchronization Readers and Writers Problem( 读者 - 写者问题 ) A data set is shared among a number of concurrent processes Readers only read the data set; they do not perform any updates Writers can both read and write Synchronization requirement allow multiple readers to read at the same time Only one single writer can access the shared data at the same time Baili Zhang/ Southeast 52 26

27 6.6 Classic Problems of Synchronization Shared Data Data set Semaphore mutex initialized to 1 Semaphore wrt initialized to 1 Integer readcount initialized to 0 Baili Zhang/ Southeast Classic Problems of Synchronization The structure of a writer process do { wait (wrt) ; // Critical Section // writing is performed signal (wrt) ; } while (TRUE); Baili Zhang/ Southeast 54 27

28 6.6 Classic Problems of Synchronization The structure of a reader process do { wait (mutex) ; readcount ++ ; //Critical Section if (readcount == 1) wait (wrt) ; signal (mutex) // reading is performed wait (mutex) ; readcount - - ; // Critical Section if (readcount == 0) signal (wrt) ; signal (mutex) ; } while (TRUE); Baili Zhang/ Southeast Classic Problems of Synchronization Dining-Philosophers Problem Shared data Bowl of rice (data set) Semaphore chopstick [5] initialized to 1 Baili Zhang/ Southeast 56 28

29 6.6 Classic Problems of Synchronization The structure of Philosopher i: do { wait ( chopstick[i] ); wait ( chopstick[ (i + 1) % 5] ); // eat signal ( chopstick[i] ); signal (chopstick[ (i + 1) % 5] ); // think } while (TRUE); Baili Zhang/ Southeast Classic Problems of Synchronization The solution guarantees that no two neighbors are eating simultaneously, but it can create a deadlock Suppose that five Philosophers grab his left chopstick simultaneously several solutions to deadlock problem (1) Allow at most four philosophers to be sitting simultaneously at table (to eat) Baili Zhang/ Southeast 58 29

30 6.6 Classic Problems of Synchronization semaphore coord = 4; // Only four philosophers can try to eat simultaneously do { wait(coord); wait(chopstick[i]) wait(chopstick[(i+1) % 5]) eat signal(chopstick[i]); signal(chopstick[(i+1) % 5]); signal(coord); think } while (true); Baili Zhang/ Southeast Classic Problems of Synchronization (2) Allow a philosophers to pick up his chopsticks only if both chopsticks are available (3) Use an asymmetric solution An odd philosopher picks up first his left chopstick and then his right chopstick An even philosopher picks up first his right chopstick and then his left chopstick A deadlock-free solution does not necessarily eliminate the possibility of starvation Baili Zhang/ Southeast 60 30

31 6. Process synchronization 6.1 Background 6.2 The Critical-Section Problem 6.3 Peterson s Solution 6.4 Synchronization Hardware 6.5 Semaphores 6.6 Classic Problems of Synchronization 6.7 Monitors 6.8 Synchronization Examples 6.9 Atomic Transactions Baili Zhang/ Southeast Monitors Background Although semaphores provide a convenient and effective mechanism for synchronization Programmers must be very careful to use them Incorrect use result in timing errors that are difficult to detect These errors happen only if some particular execution sequences take place and these sequences do occur rarely These difficulties will arise even if a single process is not well behaved This situation may be caused by an honest programming error or an uncooperative programmer Baili Zhang/ Southeast 62 31

32 6.7 Monitors Incorrect use of semaphore operations signal (mutex). wait (mutex) // no mutual exclusion wait (mutex) wait (mutex) // deadlock Omitting of wait (mutex) or signal (mutex) (or both) Omitting of wait (mutex) //no mutual exclusion Omitting of signal (mutex) // deadlock These errors can be generated easily To deal with such errors, researchers have developed high-level language constructs monitor Baili Zhang/ Southeast Monitors Usage of monitor A high-level abstraction of resources that provides a convenient and effective mechanism for process synchronization monitor monitor-name { private local declarations ; public procedure P1 ( ) {. } public procedure Pn ( ) { } Initialization code (.) { } } Only one process may be active within the monitor at a time Baili Zhang/ Southeast 64 32

33 6.7 Monitors Baili Zhang/ Southeast Monitors Example: Dining Philosophers Each philosopher I invokes the operations pickup()and putdown() in the following sequence: Philosopher(i) { dp.pickup(i); eat dp.putdown(i) } Baili Zhang/ Southeast 66 33

34 6.7 Monitors The programmer doesn t need to code this synchronization constraint explicitly The complier is used to ensure the synchronization constraint But the monitor construct is not sufficiently powerful for modeling some synchronization For example: reader-writer problem, Dining Philosophers The programmer needs to write a tailormade synchronization scheme by defining one or more variables of type condition Baili Zhang/ Southeast Monitors Condition variable To allow a process to wait within the monitor, a condition variable must be declared as condition x, y; 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(); (just as block() on x, different from Semaphore wait(s);) The operation x.signal (); resumes exactly one suspended process. If no process is suspended, then the signal operation has no effect. (different from Semaphore signal(s)) Baili Zhang/ Southeast 68 34

35 6.7 Monitors Baili Zhang/ Southeast Monitors Alternative action after x.signal () P : the process that invoke signal() Q: the process that is suspended associate with x (1)Signal and wait(hoare). P waits until Q either leaves the monitor or waits for another condition (2)signal and continue Q either waits until P leaves the monitor or waits for another condition Positive: P was already executing in the monitor, it seems reasonable that let P continue Negtive: P continues, by the time Q is resumed, the logical condition for Q was waiting may no longer hold Baili Zhang/ Southeast 70 35

36 6.7 Monitors (3)improved Signal and wait (Hansen) signal() is the lastest statement before leaving the monitor When P executes the signal(), it leaves the monitor immediately Q is immediately resumed Baili Zhang/ Southeast Monitors Solution to Dining Philosophers using monitor monitor DP { enum { THINKING; HUNGRY, EATING) state [5] ; condition self [5]; void pickup (int i) { state[i] = HUNGRY; test(i); if (state[i]!= EATING) self [i].wait; // i can delay herself when she is hungry but } // is unable to obtain the chopsticks void putdown (int i) { state[i] = THINKING; // test left and right neighbors test((i + 4) % 5); //signal and wait (Hansen) test((i + 1) % 5); } Baili Zhang/ Southeast 72 36

37 6.7 Monitors void test (int i) { if ( (state[(i + 4) % 5]!= EATING) && (state[i] == HUNGRY) && (state[(i + 1) % 5]!= EATING) ) { state[i] = EATING ; //i can eat only when two neighbor aren t earting self[i].signal () ; //take effect when invoke by putdown(), 解放自己 } } } initialization_code() { for (int i = 0; i < 5; i++) state[i] = THINKING; } Baili Zhang/ Southeast Monitors Each philosopher I invokes the operations pickup()and putdown() in the following sequence: Philosopher(i) { dp.pickup(i); eat dp.putdown(i) } Can ensure that no two neighbors are not eating simultaneously and that no deadlock It is possible for a philosopher to starve to death Baili Zhang/ Southeast 74 37

38 6.7 Monitors Monitor Implementation Using Semaphores Implementing mutual exclusion Variables semaphore mutex; // (initially = 1) semaphore next; // (initially = 0) // 用于 signal() 之后阻塞自己 int next_count = 0; // 阻塞于 next 的数量 Each procedure F will be replaced by (compiler does it) wait(mutex); body of F; if (next_count > 0) signal(next); // 唤醒内部阻塞进程 else signal(mutex); // 唤醒外部阻塞进程 Baili Zhang/ Southeast Monitors Implementing the condition variable 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++; // 等待 x 的队列增加 if (next_count > 0) signal(next); // 唤醒内部 next 队列中的进程 else signal(mutex); // 唤醒外部阻塞进程 wait(x_sem); // 阻塞自己 x_count--; // 被唤醒后, 等待 x 的队列减少 } Baili Zhang/ Southeast 76 38

39 6.7 Monitors The operation x.signal() can be implemented as: if (x_count > 0) { next_count++; // 内部 next 队列 signal(x_sem); } // 释放了 x 资源, 唤醒阻塞于此进程 wait(next); // 阻塞自己 Hoare 方式 next_count--; // 被唤醒后, next 队列减少 Baili Zhang/ Southeast Monitors Resuming processes within a monitor When a x.signal() is executed If several processes are suspended on x How to determine which processes to resume FCFS Is too simply to being adequate in many circumstance Conditional-wait Baili Zhang/ Southeast 78 39

40 6.7 Monitors Conditional-wait construct: x.wait(c) c integer expression evaluated when the wait operation is executed. value of c (a 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. Baili Zhang/ Southeast Monitors A example: monitor ResourceAllocator { boolean busy; condition x; void acquire(int time) { if (busy) x.wait(time); busy = true; } //time 预计使用资源的时间 void release() { busy = false; x.signal(); } } void init() { busy = false; } Baili Zhang/ Southeast 80 40

41 6.7 Monitors Accessing the resource R.acquire(t) access the resource; R.release(); Baili Zhang/ Southeast Monitors The monitor concept cannot guarantee that the preceding access sequence (accessing the resource) will be observed Problems of monitor in particular A process might access a resource without first gaining access permission to the resource A process might never release a resource once it has been granted access to the resource A process might attempt to release a resource that it never requested A process might request a resource twice without first releasing Baili Zhang/ Southeast 82 41

42 solution 6.7 Monitors 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. As semaphore, we have to worry about the correct use of higher-level programmer-defined operations (such as monitor), with which the compiler can no longer assist us Baili Zhang/ Southeast exercises Baili Zhang/ Southeast 84 42

43 6. Process synchronization 6.1 Background 6.2 The Critical-Section Problem 6.3 Peterson s Solution 6.4 Synchronization Hardware 6.5 Semaphores 6.6 Classic Problems of Synchronization 6.7 Monitors 6.8 Synchronization Examples 6.9 Atomic Transactions Baili Zhang/ Southeast Synchronization Examples Examples Solaris Windows XP Linux Pthreads Baili Zhang/ Southeast 86 43

44 6.8 Synchronization Examples Solaris Synchronization To control access to critical sections Adaptive mutex ( 适应性互斥 ) Semaphores Condition variables readers-writers locks turnstiles ( 十字转门 ) Baili Zhang/ Southeast Synchronization Examples adaptive mutexes ( 适应性互斥 ) If the shared date are locked (in use by another) On a multiprocessor system if the lock is held by a thread that is running on another CPU, it spins if the lock is held by a thread that is not in run state, it blocks On a single-processor system It always blocks rather than spins Baili Zhang/ Southeast 88 44

45 6.8 Synchronization Examples Use adaptive mutexes to protect only data that are accessed by short segments The lock will be held for less than a hundred instructions For these longer code segments, semaphores and condition variables are used Baili Zhang/ Southeast Synchronization Examples Reader-writer lock To protect data that are accessed frequently but are usually accessed in read-only manner In these circumstances, reader-writer locks are more efficient than semaphores for multiple threads can read data concurrently reader-writer locks are relatively expensive to implement, so they are used on only long sections of code (e.g. DBMS) Baili Zhang/ Southeast 90 45

46 6.8 Synchronization Examples turnstiles ( 十字转门 ) Is a queue structure containing threads blocked on a lock To order the list of threads waiting to acquire either an adaptive mutex or reader-writer lock E.g. if a thread own a lock for a synchronization object (shared data), all other threads trying to acquire the lock will block for it and enter the turnstiles for that lock When the lock is released, a thread is selected from the turnstile to own the lock Baili Zhang/ Southeast Synchronization Examples Solaris gives each kernel thread its own turnstile, rather than associating a turnstile with each synchronized object A thread can be blocked only on one object at a time, this is more efficient than having a turnstile per object The turnstile for the first thread to block on a synchronization object becomes the turnstile for the object itself Subsequent threads blocking on the lock will be added to this turnstile When the first thread get the lock and ultimately releases the lock, it gains a new turnstile from system The same types of locks are implemented for user-level threads Baili Zhang/ Southeast 92 46

47 6.8 Synchronization Examples Windows XP Synchronization Kernel thread synchronization on uni-processor systems Uses interrupt masks to protect access to global resources on multiprocessor systems Uses spinlocks to protect short code segments For reasons of efficiency, the kernel ensures that a thread will never be preempted while holding a spinlock Baili Zhang/ Southeast Synchronization Examples Outer thread synchronization Dispatcher objects( 分配对象 ) are provided, which act as: Mutexes Semaphores Event: An event acts much like a condition variable They may notify a waiting thread when a desired condition occur Timers To notify one thread or some threads that a specified amount of time has expired Baili Zhang/ Southeast 94 47

48 6.8 Synchronization Examples Dispatcher objects may be Signaled state: free (unlock) A thread will not block when acquiring this object Non-signaled state: lock A thread will block when attempting to acquire this object When a dispatcher object moves to signaled, the kernel checks whether any threads are waiting this object. If so: For a mutex, kernel will select only one thread from the waiting queue For a event, kernel will select all threads from the waiting queue Baili Zhang/ Southeast Synchronization Examples Linux Synchronization Prior to kernel Version 2.6, disables interrupts to implement short critical sections Version 2.6 and later, the kernel is fully preemptive, and provides: semaphores spin locks On SMP machines Acquire spin lock and release spin lock The kernel is designed so that the spin lock is held only for short durations Baili Zhang/ Southeast 96 48

49 6.8 Synchronization Examples On single-processor machines Disable kernel preemption Preemption_count is incremented, when a lock is acquired Preemption_count is greater than zero, it is not safe to preempt the kernel, as the task hold lock(s) Enable kernel preemption Preemption_count is decremented, when a lock is released Preemption_count is zero, it is safe to be interrupted Baili Zhang/ Southeast Synchronization Examples Pthreads Synchronization Pthreads API is OS-independent It provides: mutex locks condition variables other extensions include: read-write locks spin locks Baili Zhang/ Southeast 98 49

50 6. Process synchronization 6.1 Background 6.2 The Critical-Section Problem 6.3 Peterson s Solution 6.4 Synchronization Hardware 6.5 Semaphores 6.6 Classic Problems of Synchronization 6.7 Monitors 6.8 Synchronization Examples 6.9 Atomic Transactions Baili Zhang/ Southeast Atomic Transactions System Model Assures that operations happen as a single logical unit of work, in its entirety, or not at all Related to field of database systems Challenge is assuring atomicity despite computer system failures Transaction - collection of instructions or operations that performs single logical function Here we are concerned with changes to stable storage disk Transaction is series of read and write operations Terminated by commit (transaction successful) or abort (transaction failed) operation Aborted transaction must be rolled back to undo any changes it performed Baili Zhang/ Southeast

51 6.9 Atomic Transactions Types of Storage Media Volatile storage information stored here does not survive system crashes Example: main memory, cache Nonvolatile storage Information usually survives crashes Example: disk and tape Stable storage Information never lost Not actually possible, so approximated via replication or RAID to devices with independent failure modes Goal is to assure transaction atomicity where failures cause loss of information on volatile storage Baili Zhang/ Southeast Atomic Transactions Log-Based Recovery Record to stable storage information about all modifications by a transaction Most common is write-ahead logging Log on stable storage, each log record describes single transaction write operation, including Transaction name Data item name Old value New value <T i starts> written to log when transaction T i starts <T i commits> written when T i commits Log entry must reach stable storage before operation on data occurs Baili Zhang/ Southeast

52 6.9 Atomic Transactions Log-Based Recovery Algorithm Using the log, system can handle any volatile memory errors Undo(T i ) restores value of all data updated by T i Redo(T i ) sets values of all data in transaction T i to new values Undo(T i ) and redo(t i ) must be idempotent Multiple executions must have the same result as one execution If system fails, restore state of all updated data via log If log contains <T i starts> without <T i commits>, undo(t i ) If log contains <T i starts> and <T i commits>, redo(t i ) Baili Zhang/ Southeast Atomic Transactions Checkpoints Log could become long, and recovery could take long Checkpoints shorten log and recovery time. Checkpoint scheme: 1. Output all log records currently in volatile storage to stable storage 2. Output all modified data from volatile to stable storage 3. Output a log record <checkpoint> to the log on stable storage Now recovery only includes Ti, such that Ti started executing before the most recent checkpoint, and all transactions after Ti All other transactions already on stable storage Baili Zhang/ Southeast

53 6.9 Atomic Transactions Concurrent Transactions Serializability Must be equivalent to serial execution serializability Could perform all transactions in critical section Inefficient, too restrictive Concurrency-control algorithms provide serializability serial schedule Consider two data items A and B Consider Transactions T 0 and T 1 Execute T 0, T 1 atomically Execution sequence called schedule Atomically executed transaction order called serial schedule For N transactions, there are N! valid serial schedules Baili Zhang/ Southeast Atomic Transactions Schedule 1: T 0 then T 1 Baili Zhang/ Southeast

54 6.9 Atomic Transactions Nonserial Schedule Nonserial schedule allows overlapped execute Resulting execution not necessarily incorrect Consider schedule S, operations O i, O j Conflict if access same data item, with at least one write If O i, O j consecutive and operations of different transactions & O i and O j don t conflict Then S with swapped order O j O i equivalent to S If S can become S via swapping nonconflicting operations S is conflict serializable Baili Zhang/ Southeast Atomic Transactions Baili Zhang/ Southeast

55 6.9 Atomic Transactions Locking Protocol Ensure serializability by associating lock with each data item Follow locking protocol for access control Locks Shared T i has shared-mode lock (S) on item Q, T i can read Q but not write Q Exclusive Ti has exclusive-mode lock (X) on Q, T i can read and write Q Require every transaction on item Q acquire appropriate lock If lock already held, new request may have to wait Similar to readers-writers algorithm Baili Zhang/ Southeast Atomic Transactions Two-phase Locking Protocol Generally ensures conflict serializability Each transaction issues lock and unlock requests in two phases Growing obtaining locks Shrinking releasing locks Does not prevent deadlock Baili Zhang/ Southeast

56 6.9 Atomic Transactions Timestamp-based Protocols Select order among transactions in advance timestamp-ordering Transaction T i associated with timestamp TS(T i ) before T i starts TS(T i ) < TS(T j ) if Ti entered system before T j TS can be generated from system clock or as logical counter incremented at each entry of transaction Timestamps determine serializability order If TS(T i ) < TS(T j ), system must ensure produced schedule equivalent to serial schedule where T i appears before T j Baili Zhang/ Southeast Atomic Transactions Timestamp-based Protocol Implementation Data item Q gets two timestamps W-timestamp(Q) largest timestamp of any transaction that executed write(q) successfully R-timestamp(Q) largest timestamp of successful read(q) Updated whenever read(q) or write(q) executed Timestamp-ordering protocol assures any conflicting read and write executed in timestamp order Suppose Ti executes read(q) If TS(T i ) < W-timestamp(Q), Ti needs to read value of Q that was already overwritten read operation rejected and T i rolled back If TS(T i ) W-timestamp(Q) read executed, R-timestamp(Q) set to max(r-timestamp(q), TS(T i )) Baili Zhang/ Southeast

57 6.9 Atomic Transactions Timestamp-ordering Protocol Suppose Ti executes write(q) If TS(T i ) < R-timestamp(Q), value Q produced by T i was needed previously and T i assumed it would never be produced Write operation rejected, T i rolled back If TS(T i ) < W-tiimestamp(Q), T i attempting to write obsolete value of Q Write operation rejected and T i rolled back Otherwise, write executed Any rolled back transaction T i is assigned new timestamp and restarted Algorithm ensures conflict serializability and freedom from deadlock Baili Zhang/ Southeast Atomic Transactions Baili Zhang/ Southeast

58 exercises Baili Zhang/ Southeast 115 Baili Zhang/ Southeast

59 Baili Zhang/ Southeast 117 Baili Zhang/ Southeast

60 6.9 Atomic Transactions Baili Zhang/ Southeast Process synchronization A cooperating process is one that can affect or be affected by other process Concurrent access to shared data may result in data inconsistency Baili Zhang/ Southeast

61 Critical Regions: Implementation wait(mutex); while (!B) { first_count++; if (second_count>0) signal(second_delay); else signal(mutex); wait(first_delay); first_count--; second_count++; if (first_count > 0) signal(first_delay); else signal(second_delay); wait(second_delay); second_count--; } S; if (first_count > 0) signal(first_delay); else if (second_count > 0) signal(second_delay); else signal(mutex); Baili Zhang/ Southeast 121 管程的实现? V 管程存在的问题 ( 最后 ) V Atomic Transactions Baili Zhang/ Southeast