Chapter 5 Process Synchronization Operating System Concepts 9

Chapter 5: Process Synchronization Operating System Concepts – 9 th Edition Silberschatz, Galvin and Gagne © 2013

Chapter 5: Process Synchronization n Background n The Critical-Section Problem n Peterson’s Solution n Synchronization Hardware n Mutex Locks n Semaphores n Classic Problems of Synchronization n Monitors n Synchronization Examples n Alternative Approaches Operating System Concepts – 9 th Edition 5. 2 Silberschatz, Galvin and Gagne © 2013

Objectives n To introduce the critical-section problem l Software solution l Hardware solution n To examine several problems l classical process-synchronization n To explore several tools l solve process synchronization problems Operating System Concepts – 9 th Edition 5. 3 Silberschatz, Galvin and Gagne © 2013

Background n Concurrent execution l May be interrupted at any time, partially completing execution n Concurrent access to shared data l may result in data inconsistency l Maintaining data consistency requires the orderly execution of cooperating processes n Producer and consumer problem Operating System Concepts – 9 th Edition 5. 4 Silberschatz, Galvin and Gagne © 2013

Producer while (true) { /* produce an item in next produced */ while (counter == BUFFER SIZE) ; /* do nothing */ buffer[in] = next produced; in = (in + 1) % BUFFER SIZE; counter++; } Operating System Concepts – 9 th Edition 5. 5 Silberschatz, Galvin and Gagne © 2013

Consumer while (true) { while (counter == 0) ; /* do nothing */ next consumed = buffer[out]; out = (out + 1) % BUFFER SIZE; counter--; /* consume the item in next consumed */ } Operating System Concepts – 9 th Edition 5. 6 Silberschatz, Galvin and Gagne © 2013

Race Condition n counter++ could be implemented as n register 1 = counter register 1 = register 1 + 1 counter = register 1 n counter-- could be implemented as n register 2 = counter register 2 = register 2 - 1 counter = register 2 n Execution interleaving with “count = 5” initially: S 0: producer execute register 1 = counter S 1: producer execute register 1 = register 1 + 1 S 2: consumer execute register 2 = counter S 3: consumer execute register 2 = register 2 – 1 S 4: producer execute counter = register 1 S 5: consumer execute counter = register 2 Operating System Concepts – 9 th Edition 5. 7 {register 1 = 5} {register 1 = 6} {register 2 = 5} {register 2 = 4} {counter = 6 } {counter = 4} Silberschatz, Galvin and Gagne © 2013

Critical Section Problem n Consider system of n processes {p 0, p 1, … pn-1} n Each process has critical section code l Only one process is allowed to write in critical section n Critical section problem l design protocol to solve this l Each process enters critical section with permission Operating System Concepts – 9 th Edition 5. 8 Silberschatz, Galvin and Gagne © 2013

Critical Section n General structure of process pi with CS Operating System Concepts – 9 th Edition 5. 9 Silberschatz, Galvin and Gagne © 2013

Solution to Critical-Section Problem n Mutual Exclusion l If process Pi is executing in its CS, then no other processes are allowed n Progress l If no one executes in it CS, waiting process can get in n Bounded Waiting l Guarantee limited waiting time to enter CS n Two approaches depending on kernel mode l Preemptive 4 allows preemption of process l Non-preemptive 4 Not allow preemption of a running process Operating System Concepts – 9 th Edition 5. 10 Silberschatz, Galvin and Gagne © 2013

Peterson’s Solution n Two process solution Share two variables int turn; Boolean flag[2] l “turn” indicates whose turn to enter CS l “flag[i]=true” indicates Pi is ready to enter CS l n Assumption l load and store instructions are atomic l cannot be interrupted Operating System Concepts – 9 th Edition 5. 11 Silberschatz, Galvin and Gagne © 2013

Algorithm for Process Pi do { flag[i] = true; turn = j; while (flag[j] && turn == j); critical section flag[i] = false; remainder section } while (true); n Provable that 1. Mutual exclusion is preserved 2. Progress requirement is satisfied 3. Bounded-waiting requirement is met Operating System Concepts – 9 th Edition 5. 12 Silberschatz, Galvin and Gagne © 2013

Synchronization Hardware n Protecting critical regions via locks n Uniprocessors – could disable interrupts Currently running code would execute without preemption l Generally too inefficient on multiprocessor systems l 4 Operating systems using this not broadly scalable n Special atomic hardware instructions 4 Atomic = non-interruptible Either test memory word and set value l Or swap contents of two memory words l Operating System Concepts – 9 th Edition 5. 13 Silberschatz, Galvin and Gagne © 2013

Solution to CS Problem Using Locks do { acquire lock critical section release lock remainder section } while (TRUE); Operating System Concepts – 9 th Edition 5. 14 Silberschatz, Galvin and Gagne © 2013

test_and_set Instruction n Definition: boolean test_and_set (boolean *target) { boolean rv = *target; *target = TRUE; return rv: } Operating System Concepts – 9 th Edition 5. 15 Silberschatz, Galvin and Gagne © 2013

Solution using test_and_set() n Shared boolean variable lock, initialized to FALSE n Solution: do { while (test_and_set(&lock)) ; /* do nothing */ /* critical section */ lock = false; /* remainder section */ } while (true); Operating System Concepts – 9 th Edition 5. 16 Silberschatz, Galvin and Gagne © 2013

compare_and_swap Instruction n Definition: int compare and swap(int *value, int expected, int new value) { int temp = *value; if (*value == expected) *value = new value; return temp; } Operating System Concepts – 9 th Edition 5. 17 Silberschatz, Galvin and Gagne © 2013

Solution using compare_and_swap n Shared Boolean variable lock initialized to FALSE n Each process has a local Boolean variable key n Solution: do { while (compare and swap(&lock, 0, 1) != 0) ; /* do nothing */ /* critical section */ lock = 0; /* remainder section */ } while (true); Operating System Concepts – 9 th Edition 5. 18 Silberschatz, Galvin and Gagne © 2013

Bounded-waiting Mutual Exclusion with test_and_set do { waiting[i] = true; key = true; while (waiting[i] && key) key = test_and_set(&lock); waiting[i] = false; /* critical section */ j = (i + 1) % n; while ((j != i) && !waiting[j]) j = (j + 1) % n; if (j == i) lock = false; else waiting[j] = false; /* remainder section */ } while (true); Operating System Concepts – 9 th Edition 5. 19 Silberschatz, Galvin and Gagne © 2013

Mutex Locks n Software solution acquire() and release() must be atomic l Implemented via hardware atomic instructions l Boolean variable indicates if lock is available or not l First acquire() a lock, then release() it l This solution requires busy waiting l The lock is therefore called a spinlock l Operating System Concepts – 9 th Edition 5. 20 Silberschatz, Galvin and Gagne © 2013

acquire() and release() acquire() { while (!available) ; /* busy wait */ available = false; ; } release() { available = true; } do { acquire lock critical section release lock remainder section } while (true); Operating System Concepts – 9 th Edition 5. 21 Silberschatz, Galvin and Gagne © 2013

Semaphore n Another way but does not require busy waiting n Semaphore S – integer variable n Two standard atomic operations modify S wait() and signal() l Originally called P() and V() l wait (S) { while (S <= 0) ; // busy wait S--; } signal (S) { S++; } Operating System Concepts – 9 th Edition 5. 22 Silberschatz, Galvin and Gagne © 2013

How to use Semaphore n Types l Counting semaphore 4 integer value can range over an unrestricted domain 4 l Can be implemented as a binary semaphore Binary semaphore 4 integer value can range only between 0 and 1 4 mutex lock n Synchronizing problem l Consider P 1 and P 2 that require S 1 to happen before S 2 P 1: S 1; signal(synch); P 2: wait(synch); S 2; Operating System Concepts – 9 th Edition 5. 23 Silberschatz, Galvin and Gagne © 2013

Semaphore Implementation n No two processes can l execute wait () and signal () on l the same semaphore l at the same time n The implementation becomes a CS problem l where the wait and signal code are placed in the critical section l May incur Busy Waiting l It is a good solution Operating System Concepts – 9 th Edition 5. 24 Silberschatz, Galvin and Gagne © 2013

Semaphore Implementation with no Busy waiting n Each semaphore is with an associated waiting queue n Each entry in a waiting queue has two data items: l value l pointer to next record in the list n Two operations l block 4 l place the process invoking the operation on the appropriate waiting queue wakeup 4 remove one of processes in the waiting queue, and 4 place it in the ready queue Operating System Concepts – 9 th Edition 5. 25 Silberschatz, Galvin and Gagne © 2013

Semaphore Implementation with no Busy waiting (Cont. ) typedef struct{ int value; struct process *list; } semaphore; wait(semaphore *S) { S->value--; if (S->value < 0) { add this process to S->list; block(); } } signal(semaphore *S) { S->value++; if (S->value <= 0) { remove a process P from S->list; wakeup(P); } } Operating System Concepts – 9 th Edition 5. 26 Silberschatz, Galvin and Gagne © 2013

Deadlock and Starvation n Deadlock two or more processes are waiting each other l Let S and Q be two semaphores initialized to 1 l P 0 P 1 wait(S); wait(Q); wait(S); . . signal(S); signal(Q); signal(S); n Starvation l A process may never be removed from the semaphore queue in which it is suspended n Solution l priority-inheritance protocol Operating System Concepts – 9 th Edition 5. 27 Silberschatz, Galvin and Gagne © 2013

Classical Problems of Synchronization n Bounded-Buffer n Readers and Writers n Dining-Philosophers Operating System Concepts – 9 th Edition 5. 28 Silberschatz, Galvin and Gagne © 2013

Bounded-Buffer Problem n n buffers l each can hold one item n Semaphore initialization l mutex = 1 l full = 0 l empty = n Operating System Concepts – 9 th Edition 5. 29 Silberschatz, Galvin and Gagne © 2013

Bounded Buffer Problem (Cont. ) n the producer process do {. . . /* produce an item in next_produced */. . . wait(empty); wait(mutex); . . . /* add next produced to the buffer */. . . signal(mutex); signal(full); } while (true); Operating System Concepts – 9 th Edition 5. 30 Silberschatz, Galvin and Gagne © 2013

Bounded Buffer Problem (Cont. ) n the consumer process do { wait(full); wait(mutex); . . . /* remove an item from buffer to next_consumed */. . . signal(mutex); signal(empty); . . . /* consume the item in next consumed */. . . } while (true); Operating System Concepts – 9 th Edition 5. 31 Silberschatz, Galvin and Gagne © 2013

Readers-Writers Problem n Concurrent processes share a data set l Readers 4 l only read the data set; they do not perform any updates Writers 4 can both read and write n Shared Data l Data set l Semaphore rw_mutex initialized to 1 l Semaphore mutex initialized to 1 l Integer read_count initialized to 0 Operating System Concepts – 9 th Edition 5. 32 Silberschatz, Galvin and Gagne © 2013

Readers-Writers Problem (Cont. ) n Writer process do { wait(rw mutex); . . . /* writing is performed */. . . signal(rw mutex); } while (true); Operating System Concepts – 9 th Edition 5. 33 Silberschatz, Galvin and Gagne © 2013

Readers-Writers Problem (Cont. ) n Reader process do { wait(mutex); read count++; if (read count == 1) wait(rw mutex); signal(mutex); . . . /* reading is performed */. . . wait(mutex); read count--; if (read count == 0) signal(rw mutex); signal(mutex); } while (true); Operating System Concepts – 9 th Edition 5. 34 Silberschatz, Galvin and Gagne © 2013

Readers-Writers Problem Variations n First variation l no reader kept waiting unless writer has permission to use shared object n Second variation l once writer is ready, it performs write asap n Both may have starvation leading to even more variations l Solved by kernel providing reader-writer locks Operating System Concepts – 9 th Edition 5. 35 Silberschatz, Galvin and Gagne © 2013

Dining-Philosophers Problem n Philosophers spend their lives thinking and eating n Don’t interact with their neighbors, occasionally try to pick up 2 chopsticks (one at a time) to eat from bowl l n Need both to eat, then release both when done In the case of 5 philosophers l Shared data 4 Bowl of rice (data set) 4 Semaphore chopstick [5] initialized to 1 Operating System Concepts – 9 th Edition 5. 36 Silberschatz, Galvin and Gagne © 2013

Dining-Philosophers Problem Algorithm n The structure of Philosopher i: do { wait ( chopstick[i] ); wait ( chop. Stick[ (i + 1) % 5] ); // eat signal ( chopstick[i] ); signal (chopstick[ (i + 1) % 5] ); // think } while (TRUE); n What is the problem with this algorithm? Operating System Concepts – 9 th Edition 5. 37 Silberschatz, Galvin and Gagne © 2013

Problems with Semaphores n Incorrect use of semaphore operations: l signal (mutex) …. wait (mutex) l wait (mutex) … wait (mutex) l Omitting of wait (mutex) or signal (mutex) (or both) n Deadlock n Starvation Operating System Concepts – 9 th Edition 5. 38 Silberschatz, Galvin and Gagne © 2013

Monitors n Another way to synchronize processes n Features A high-level abstraction l a convenient and effective mechanism l Abstract data type 4 internal variables only accessible by code within the procedure l Only one process may be active within the monitor at a time l n Disadvantage l not powerful enough to model some synchronization schemes monitor-name { // shared variable declarations procedure P 1 (…) { …. } … procedure Pn (…) {……} Initialization code (…) { … } } } Operating System Concepts – 9 th Edition 5. 39 Silberschatz, Galvin and Gagne © 2013

Schematic view of a Monitor Operating System Concepts – 9 th Edition 5. 40 Silberschatz, Galvin and Gagne © 2013

Condition Variables n condition x, y; n Two operations on a condition variable: l x. wait () 4 l a process that invokes the operation is suspended until x. signal () 4 resumes one of processes (if any) that invoked x. wait () 4 If no x. wait () on the variable, then it has no effect on the variable Operating System Concepts – 9 th Edition 5. 41 Silberschatz, Galvin and Gagne © 2013

Monitor with Condition Variables Operating System Concepts – 9 th Edition 5. 42 Silberschatz, Galvin and Gagne © 2013

Condition Variables Choices n Question? l If process P invokes x. signal (), with Q in x. wait () state, what should happen next? l If Q is resumed, then P must wait n Options include l Signal and wait 4 l P waits until Q leaves monitor or waits for another condition Signal and continue 4 Q waits until P leaves the monitor or waits for another condition n Depends on implementing language l Pascal 4 l P executing signal immediately leaves the monitor, Q is resumed Implemented in other languages including Mesa, C#, Java Operating System Concepts – 9 th Edition 5. 43 Silberschatz, Galvin and Gagne © 2013

Monitor Solution to Dining Philosophers monitor Dining. Philosophers { 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; } void putdown (int i) { state[i] = THINKING; // test left and right neighbors test((i + 4) % 5); test((i + 1) % 5); } Operating System Concepts – 9 th Edition 5. 44 Silberschatz, Galvin and Gagne © 2013

Solution to Dining Philosophers (Cont. ) void test (int i) { if ( (state[(i + 4) % 5] != EATING) && (state[i] == HUNGRY) && (state[(i + 1) % 5] != EATING) ) { state[i] = EATING ; self[i]. signal () ; } } initialization_code() { for (int i = 0; i < 5; i++) state[i] = THINKING; } } Operating System Concepts – 9 th Edition 5. 45 Silberschatz, Galvin and Gagne © 2013

Solution to Dining Philosophers (Cont. ) n Each philosopher i l invokes the operations pickup() and putdown() in the following sequence: Dining. Philosophers. pickup (i); EAT Dining. Philosophers. putdown (i); n No deadlock n Starvation is possible Operating System Concepts – 9 th Edition 5. 46 Silberschatz, Galvin and Gagne © 2013

Monitor Implementation Using Semaphores n Variables semaphore mutex; // (initially = 1) semaphore next; // (initially = 0) int next_count = 0; n Each procedure F will be replaced by wait(mutex); … body of F; … if (next_count > 0) signal(next) else signal(mutex); n Mutual exclusion within a monitor is ensured Operating System Concepts – 9 th Edition 5. 47 Silberschatz, Galvin and Gagne © 2013

Monitor Implementation – Condition Variables n For each condition variable x, we have: semaphore x_sem; // (initially = 0) int x_count = 0; n The operation x. wait can be implemented as: x-count++; if (next_count > 0) signal(next); else signal(mutex); wait(x_sem); x-count--; Operating System Concepts – 9 th Edition 5. 48 Silberschatz, Galvin and Gagne © 2013

Monitor Implementation (Cont. ) n x. signal implementation if (x-count > 0) { next_count++; signal(x_sem); wait(next); next_count--; } Operating System Concepts – 9 th Edition 5. 49 Silberschatz, Galvin and Gagne © 2013

Resuming Processes within a Monitor n Question l If several processes queued on condition x, l and x. signal() executed, l which should be resumed? n conditional-wait l construct of the form x. wait(c) l Where c is priority number l Process with lowest number (highest priority) is scheduled next Operating System Concepts – 9 th Edition 5. 50 Silberschatz, Galvin and Gagne © 2013

A Monitor to Allocate Single Resource monitor Resource. Allocator { boolean busy; condition x; void acquire(int time) { if (busy) x. wait(time); busy = TRUE; } void release() { busy = FALSE; x. signal(); } initialization code() { busy = FALSE; } } Operating System Concepts – 9 th Edition 5. 51 Silberschatz, Galvin and Gagne © 2013

Synchronization Examples n Solaris n Windows XP n Linux n Pthreads Operating System Concepts – 9 th Edition 5. 52 Silberschatz, Galvin and Gagne © 2013

Solaris n Implements a variety of locks to support l Multitasking l multithreading (including real-time threads), and l multiprocessing n Features l Uses adaptive mutexes 4 for efficiency when protecting data from short code segments 4 Starts as a standard semaphore spin-lock 4 If lock held, and by a thread running on another CPU, spins 4 If lock held by non-run-state thread, block and sleep waiting for signal of lock being released l Uses condition variables l Uses readers-writers locks 4 l when longer sections of code need access to data Uses turnstiles to order the list of threads 4 waiting to acquire either an adaptive mutex or reader-writer lock 4 Turnstiles are per-lock-holding-thread, not per-object Operating System Concepts – 9 th Edition 5. 53 Silberschatz, Galvin and Gagne © 2013

Windows XP n Uses interrupt masks l on uniprocessor systems l to protect access to global resources n Uses spinlocks l on multiprocessor systems l Spinlocking-thread will never be preempted n Provides dispatcher objects l l may act mutexes, semaphores, events, and timers Events 4 An event acts much like a condition variable l Timers notify one or more thread when time expired l Dispatcher objects 4 either signaled-state (object available) 4 or non-signaled state (thread will block) Operating System Concepts – 9 th Edition 5. 54 Silberschatz, Galvin and Gagne © 2013

Linux n Points l Prior to kernel Version 2. 6, disables interrupts to implement short critical sections l Version 2. 6 and later, fully preemptive n Provides: l semaphores l Spinlocks 4 l On single-cpu system, spinlocks replaced by enabling and disabling kernel preemption reader-writer versions of both Operating System Concepts – 9 th Edition 5. 55 Silberschatz, Galvin and Gagne © 2013

Pthreads n Pthreads API is OS-independent n Provides l mutex locks l condition variables n Non-portable extensions include l read-write locks l spinlocks Operating System Concepts – 9 th Edition 5. 56 Silberschatz, Galvin and Gagne © 2013

Atomic Transactions n System Model n Log-based Recovery n Checkpoints n Concurrent Atomic Transactions Operating System Concepts – 9 th Edition 5. 57 Silberschatz, Galvin and Gagne © 2013

System Model n Assures that operations happen as a single logical unit of work n Related to field of database systems n Challenge is assuring atomicity despite computer system failures n Transaction l collection of instructions or operations that performs single logical function l Here we are concerned with changes to stable storage – disk l Transaction is series of read and write operations l Terminated by commit (transaction successful) or abort (transaction failed) operation l Aborted transaction must be rolled back to undo any changes it performed Operating System Concepts – 9 th Edition 5. 58 Silberschatz, Galvin and Gagne © 2013

Types of Storage Media Goal is to assure transaction atomicity where failures cause loss of information on volatile storage n Volatile storage l information stored here does not survive system crashes l Example: main memory, cache n Nonvolatile storage l Information usually survives crashes l Example: disk and tape n Stable storage l Information never lost l replication or RAID to devices with independent failure modes Operating System Concepts – 9 th Edition 5. 59 Silberschatz, Galvin and Gagne © 2013

Log-Based Recovery n Record l to stable storage information about all modifications by a transaction n write-ahead logging l each log record describes single transaction write operation, including 4 Transaction name 4 Data item name 4 Old value 4 New value l <Ti starts> written to log when transaction Ti starts l <Ti commits> written when Ti commits Operating System Concepts – 9 th Edition 5. 60 Silberschatz, Galvin and Gagne © 2013

Log-Based Recovery Algorithm n Using the log l system can handle any volatile memory errors l Undo(Ti) restores value of all data updated by Ti l Redo(Ti) sets values of all data in transaction Ti to new values l Undo(Ti) and redo(Ti) must be idempotent l Multiple executions must have the same result as one execution n If system fails, l restore state of all updated data via log l If log contains <Ti starts> without <Ti commits>, undo(Ti) l If log contains <Ti starts> and <Ti commits>, redo(Ti) Operating System Concepts – 9 th Edition 5. 61 Silberschatz, Galvin and Gagne © 2013

Checkpoints n The problem using Log-based recovery l Log could become long, and l recovery could take long n Checkpoints l shorten log and recovery time n 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 n Recovery l only includes Ti l Ti started executing before the most recent checkpoint, and all transactions after Ti l All other transactions already on stable storage Operating System Concepts – 9 th Edition 5. 62 Silberschatz, Galvin and Gagne © 2013

Concurrent Transactions n Must be equivalent to serial execution – serializability n Could perform all transactions in critical section l Inefficient, too restrictive n Concurrency-control algorithms provide serializability Operating System Concepts – 9 th Edition 5. 63 Silberschatz, Galvin and Gagne © 2013

Serializability n Consider two data items A and B n Consider Transactions T 0 and T 1 n Execute T 0, T 1 atomically n Execution sequence called schedule n Atomically executed transaction order called serial schedule n For N transactions, there are N! valid serial schedules Operating System Concepts – 9 th Edition 5. 64 Silberschatz, Galvin and Gagne © 2013

Schedule 1: T 0 then T 1 Operating System Concepts – 9 th Edition 5. 65 Silberschatz, Galvin and Gagne © 2013

Nonserial Schedule n Non-serial schedule l allows overlapped execute l Resulting execution not necessarily incorrect n Example l Consider schedule S, operations Oi, Oj l Conflict if access same data item, with at least one write l If Oi, Oj consecutive and operations of different transactions & Oi and Oj don’t conflict l Then S’ with swapped order Oj Oi equivalent to S l If S can become S’ via swapping nonconflicting operations 4 S is conflict serializable Operating System Concepts – 9 th Edition 5. 66 Silberschatz, Galvin and Gagne © 2013

Schedule 2: Concurrent Serializable Schedule Operating System Concepts – 9 th Edition 5. 67 Silberschatz, Galvin and Gagne © 2013

Locking Protocol n Ensure serializability l by associating lock with each data item l Follow locking protocol for access control n Locks l Shared 4 l Ti has shared-mode lock (S) on item Q, Ti can read Q but not write Q Exclusive 4 Ti has exclusive-mode lock (X) on Q, Ti can read and write Q n Requirements l every transaction on item Q acquire appropriate lock is required l If lock already held, new request may have to wait 4 Similar to readers-writers algorithm Operating System Concepts – 9 th Edition 5. 68 Silberschatz, Galvin and Gagne © 2013

Two-phase Locking Protocol n Generally ensures conflict serializability n Each transaction issues lock and unlock requests in two phases l Growing – obtaining locks l Shrinking – releasing locks n Does not prevent deadlock Operating System Concepts – 9 th Edition 5. 69 Silberschatz, Galvin and Gagne © 2013

Timestamp-based Protocols n Timestamp-ordering l Select order among transactions in advance l Transaction Ti associated with timestamp TS(Ti) before Ti starts l 4 TS(Ti) < TS(Tj) if Ti entered system before Tj 4 TS can be generated from system clock or as logical counter incremented at each entry of transaction Timestamps determine serializability order 4 If TS(Ti) < TS(Tj), system must ensure produced schedule equivalent to serial schedule 4 where Ti appears before Tj Operating System Concepts – 9 th Edition 5. 70 Silberschatz, Galvin and Gagne © 2013

Timestamp-based Protocol Implementation n Data item Q gets two timestamps l W-timestamp(Q) 4 l R-timestamp(Q) 4 l largest timestamp of any transaction that executed write(Q) successfully largest timestamp of successful read(Q) Updated whenever read(Q) or write(Q) executed n Timestamp-ordering protocol assures any conflicting read and write executed in timestamp order l Suppose Ti executes read(Q) l 4 4 If TS(Ti) < W-timestamp(Q), Ti needs to read value of Q that was already overwritten – read operation rejected and Ti rolled back If TS(Ti) ≥ W-timestamp(Q) – read executed, R-timestamp(Q) set to max(R-timestamp(Q), TS(Ti)) Operating System Concepts – 9 th Edition 5. 71 Silberschatz, Galvin and Gagne © 2013

Timestamp-ordering Protocol n Suppose Ti executes write(Q) l l l If TS(Ti) < R-timestamp(Q) 4 value Q produced by Ti was needed previously and Ti assumed it would never be produced 4 Write operation rejected, Ti rolled back If TS(Ti) < W-timestamp(Q) 4 Ti attempting to write obsolete value of Q 4 Write operation rejected and Ti rolled back Otherwise, write executed n Any rolled back transaction l Ti is assigned new timestamp and restarted n Algorithm ensures l conflict serializability and l freedom from deadlock Operating System Concepts – 9 th Edition 5. 72 Silberschatz, Galvin and Gagne © 2013

Schedule Possible Under Timestamp Protocol Operating System Concepts – 9 th Edition 5. 73 Silberschatz, Galvin and Gagne © 2013

End of Chapter 5 Operating System Concepts – 9 th Edition Silberschatz, Galvin and Gagne © 2013