CHAPTER 7 PROCESS SYNCHRONIZATION CGS 3763 Operating System

CHAPTER 7 PROCESS SYNCHRONIZATION CGS 3763 - Operating System Concepts UCF, Spring 2004 1

COOPERATING PROCESSES • Independent processes cannot affect or be affected by the execution of another process. • Dependent processes can affect or be affected by the execution of another process – a. k. a. , Cooperating Processes • Processes may cooperate for: – – Information sharing Computation speed-up (Requires 2 or more CPUs) Modularity Convenience 2

REQUIREMENTS FOR COOPERATION • In order to cooperate, processes must be able to: – Communicate with one another • Passing information between two or more processes – Synchronize their actions • coordinating access to shared resources – hardware (e. g. , printers, drives) – software (e. g. , shared code) – files (e. g. , data or database records) – variables (e. g. , shared memory locations) • Concurrent access to shared data may result in data inconsistency. • Maintaining data consistency requires synchronization mechanisms to ensure the orderly execution of cooperating processes – Synchronization itself requires some form of communication 3

PROCESS SYNCHRONIZATION • Particularly important with concurrent execution • Can cause two major problems: – Race Condition • When two or more cooperating processes access and manipulate the same data concurrently, and • the outcome of the execution depends on the order in which the access takes place. – Deadlock (Chapter 8) • When two or more waiting processes require shared resource for their continued execution • but the required resources are held by other waiting processes 4

RACE CONDITION • Cooperating processes have within their programs “critical sections” – A code segment during which a process accesses and changes a common variable or data item. – When one processes is in its critical section, no other process must execute in its own critical section. – Execution of critical sections with respect to the same shared variable or data item must be mutually exclusive • A race condition occurs when two processes execute critical sections in a non-mutually exclusive manner. 5

RACE CONDITION EXAMPLES • File Level Access – Editing files in a word processor • Record Level Access – Modifying a data base record • Shared Variable Level P 1 : LOAD X X = X+1 STORE X : P 2 : LOAD X X = X+1 STORE X : • Final value for X based on execution sequence 6

RACE CONDITION EXAMPLES (cont. ) • Think of concurrent access as a series of sequential instructions with respect to the shared variable, data or resource. • If no interrupts during each code section: X = 1051 • If interrupts do occur results may vary: X = 51 or 1050 7

PREVENTING RACE CONDITIONS • Two options (policies) for preventing race conditions: – we must make sure that each process executes its critical section without interruption (PROBLEMS? ? ) – make other processes wait until the current process completes execution of its critical section • Any mechanism for solving the critical section problem must meet the following: – Mutual Exclusion - Only one process at a time may execute in its critical section – Progress - Processes must be allowed to execute their critical sections at some time – Bounded Waiting - Cannot prevent a process from executing its critical section indefinitely 8

SOLUTIONS TO CRITICAL SECTION PROBLEM • Text book contains various software and hardware solutions to the critical section problem: – Algorithm 1 (software/shared memory): • Uses turn variable to alternate entry into critical sections between two processes • Assures mutual exclusion but not progress requirement – Algorithm 2 (software/shared memory): • Uses flag variables to show requests by processes wishing to enter their critical sections. • Assures mutual exclusion but not progress requirement – Algorithm 3 (software/shared memory): • Uses flags to show requests, then turn to break tie • Meets all three requirements but only for two processes 9

SOLUTIONS TO CRITICAL SECTION PROBLEM (cont. ) • Swap/Test-and-Set (hardware/software/shared memory) • Executed as atomic or indivisible instructions. • Allows process to test status of a “lock” variable and set lock at same time. • Can execute critical section only if unlocked. • Can be used to simplify programming of synchronization algorithms. 10

SOLUTIONS (cont. ) • Previous examples require: – OS to provide shared memory locations for variables (turn, flags, locks) – But programmers are responsible for how that shared memory is used. • Must write lots of code to support these types of solutions • Must write correct code • Algorithms 1, 2 & 3 (even with hardware support) become very complicated when more than two processes require access to critical sections referencing the same shared variable/resource. 11

SOLUTIONS (cont. ) • Need more robust solution: – Should be managed by the OS or supported by HLL – Should work with two or more processes – Should not require application process control or masking of interrupts – Should be workable in multi-processor environments (parallel systems) – Should keep processes from executing in the running state (busy/waiting loops or no-ops) while waiting their turn • Must also meet our three requirements: – Mutual exclusion, progress, bounded waiting 12

ROBUST SOLUTIONS • Critical Regions – High Level Language (HLL) construct for controlling execution of critical sections – Code oriented solution – Regions referring to the same shared variable exclude each other in time. • Monitors – High Level Language (HLL) construct for managing the shared variable/resource referenced in critical sections – More object- or data-oriented solution – allows the safe sharing of an abstract data type among concurrent processes 13

ROBUST SOLUTIONS (cont. ) • Semaphores – Can be managed by OS or applications programmer – Processes execute P( ) operation before entering critical section – Processes execute V( ) operation after leaving critical section – P( ) and V( ) can be a type of system call 14

SEMAPHORES • Uses a shared variable s (can be owned by OS) – Initialized to “ 1” • P(s) - Atomic Operation (aka wait) – Decrement value of s by 1 – If s<0, block process • Move process from running state to wait_semaphore_s queue • V(s) - Atomic Operation (aka signal) – Increment value of s by 1 – If s <=0, unblock a waiting process • Move process from wait_semaphore_s queue to ready queue • Usually use FCFS/FIFO to ensure progress 15

SEMAPHORES (cont. ) • Semaphores can be used for more than just critical section solutions – Can be used to control access to resources • for example, printers, files, records) • The P( ) and V( ) operations described in previous slide use a “counting” semaphore. – Negative values of s tell how many processes are waiting to access the share resource associated with the semaphore. – Can initialize s to number other than 1 if more instances of the resource (e. g. , printer) exist 16