Cosc 4740 Chapter 6, Part 3 Process Synchronization

OS Synchronization Sun Solaris implementation Windows XP implementation Linux implementations Atomic transactions

Solaris Synchronization Implements a variety of locks to support multitasking, multithreading (including real- time threads), and multiprocessing. Uses adaptive mutexes for efficiency when protecting data from short code segments.

Adaptive Mutexes Protects every critical data item With a multiprocessor system, it has two functions and if the data is locked 1.If lock is held by running thread, then use a spinlock (busy loop). 2.If lock is held by blocked thread, then process blocks. Single processor, uses only #2

Uses condition variables and readers-writers locks when longer sections of code need access to data. –Readers-Writers locks protect data is read often, but needs little updating. Uses turnstiles to order the list of threads waiting to acquire either an adaptive mutex or reader- writer lock. –turnstiles: data structure containing threads blocked on a lock

Windows XP Synchronization Uses interrupt masks to protect access to global resources on uniprocessor systems. Uses spinlocks on multiprocessor systems. –Also protects spinlocks, by not allowing a process to be preempted when holding a spinlock. Also provides dispatcher objects which may act as mutexes and semaphores.

Dispatcher objects may also provide events. –An event acts much like a condition variable (monitors). –It will signal when blocked processes on a waiting queue, when the resource is available.

Linux Synchronization Linux: –Prior to kernel Version 2.6, disables interrupts to implement short critical sections –Version 2.6 and later, fully preemptive Linux provides: –semaphores –spinlocks –reader-writer versions of both On single-cpu system, spinlocks replaced by enabling and disabling kernel preemption

Pthreads Synchronization Pthreads API is OS-independent It provides: –mutex locks –condition variables Non-portable extensions include: –read-write locks –spin locks

Atomic Transactions Database principles for O/S actions –Mainly, storage, retrieval of data, and consistency –File system management and shared memory.

System Model Transaction: a series of operations (instructions) that performs a single logical function –A sequence of reads and writes for file systems –The action is either committed or aborted –When an action is aborted, then the “system” is rolled back to a stable state. Allows for failure of the system, but the file system is easily recovered and undamaged.

Log-Based Recovery A record of each action is recorded, before the action takes place. Called write-ahead logging Known as journaling for File systems In the log –Transaction name (unique name of transaction) –Data Item Name (unique name of data item written) –Old value –New value

Log-Based Recovery (2) If the action failures to commit, then issue and undo or redo (depends on the system) –Undo returns to the state before the action started. –Redo attempts to finish the action (good for file system recovery)

Checking points When a failure occurs, we need to check the log and determine what to do. Can very time-consuming So reduce overhead, log is written out and put a checkpoint in log, to state it has gotten this far. –An action may have completed, but not committed yet.

Serializability Serialize atomic actions –Since they are atomic and can interfere with actions of another they can be executed in an arbitrary order –May not always produce the same final answer though.

Schedule 1: T 0 then T 1

Schedule 2: Concurrent Serializable Schedule

Locking Protocol and Timestamp- Based Protocols Each works to ensure that final result comes out as expected, by ordering the serial atomic actions. Locking Protocol, required to get the locks as they did the first time. Timestamp, use extra information with timestamps of reads and writes.

Next Time Chapter 6.9: Deadlock! –Deadlock Prevention and Avoidance –Deadlock Detection and Recovery

Q A &