An Operating Systems Vade Mecum

The problems 257operating systems. From another point of view, most of the solutions we will look athave a linguistic flavor; that is, we will build programming-language structures to help usenforce our policies and hide the complexity of the algorithms. To some extent, therefore,our problem is in the domain of programming languages. Concurrency control isnot the only problem in which operating systems and programming languages havemutual interests. We will touch upon communication later as another example.1 THE PROBLEMSConcurrency control is a problem of resource management. When we looked at allocationof sequentially reusable resources, we characterized policies as liberal or conservative.The same characterization applies in the realm of concurrency control. A policycan be very liberal, allowing shared data to be accessed almost whenever an activitypleases. Such a strategy achieves the goal of simultaneous access and a high degree ofparallelism. The danger of liberal strategies is that some execution orders lead to erroneousresults. At the other extreme, a policy can be very conservative, blocking accessesuntil it is certain that erroneous results cannot arise. The danger of conservative strategiesis that activities are unable to respond efficiently to real-time events.Deadlock and starvation are dangers for any policy that occasionally blocks activities.As we saw in Chapter 4, deadlock occurs when activities are waiting for each otherso that none can run, and starvation is a situation in which some blocked activity is consistentlypassed over and not allowed to run. A related danger is livelock, a situation inwhich the algorithm that decides whether to block an activity continues to run withoutreaching a decision. A special case of livelock is busy waiting, in which an activity usescomputational resources without making progress as an alternative to blocking. Busywaiting is not objectionable if there is no other work worth doing during the wait.Before we proceed with solutions, let’s review the typical situation in which simultaneousaccess can lead to errors.process Aprocess B1 TmpA := x; TmpB := x;2 TmpA := TmpA + 1; TmpB := TmpB + 1;3 x := TmpA; x := TmpB;Assume that TmpA and TmpB are variables local to processes A and B and that x is avariable shared between them. Assume that x starts with value 0. After both A and Bhave finished their fragments of code, x has the value 2 if we are lucky and 1 if we arenot: If both processes execute statement 1 before either executes statement 3, then eachwill read an old x value of 0 and update it in line 3 to a 1.Here is a simpler situation that can also lead to trouble.