This material taken from Module 6 of CSE2302 Operating Systems
Context is Process Synchronization: How do we get two independent processes to synchronize their operations in a reliable, correct, fashion?
Why is this difficult? To answer this question, first look at the Mutual Update Problem.
Learning Objective:To understand the Mutual Update Problem, how it arises, and the need for atomic operations in its solution.
Concurrent access to shared data may result in data inconsistency.
Can characterize problem thus:
Suppose we have two processes A and B that both want to update some shared variable n
Each does n := n + 1, which involves reading the value of n, adding 1 to it, and then storing the result back to n. Call these operations R, I, S for read, increment, store.
Process A performs operations RA, IA, SA in order; while process B does RB, IB, SB, also in order
What happens when the speed of execution of R,I,S varies, and process A overlaps with process B?
The problem arises because while the order of each RA, IA, SA; and RB, IB, SB is guaranteed by program semantics within a single process, it is not guaranteed between concurrent processes. This is called a race condition, since the actual result depends upon the interleaving of the instructions
Consider the following scenarios, assuming n=3:
|
|
In both cases, the value of n ends up as 4, when it should be 5
How do we solve the Mutual Update Problem?
Note that the correct behaviour is guaranteed if we make sure each R,I,S sequence is not overlapped with the other:
|
|
The order of whether A goes first or B goes first does not matter, as long as they do not overlap
The read, increment and store operations must be performed as an atomic operation.
Sections of code that access shared variables (such as n) are known as critical regions
No two processes can be executing in critical regions simultaneously. This ensures the operations in the critical region are performed atomically.
This is the basis for understanding much of concurrent process synchronization, and database locking protocols (to follow).
249 accesses since 10 Oct 2008, HTML cache rendered at 20090821:0730