Chapter Six -- Synchronization Tools -- Lecture Notes

• 6.0 Objectives
  • Describe the critical-section (CS) problem and illustrate a race condition
  • Illustrate hardware solutions to the CS problem using memory barriers, compare-and-swap operations, and atomic variables.
  • Demonstrate how mutex locks, semaphores, monitors, and condition variables can be used to solve the CS problem
  • Evaluate tools that solve the CS problem in low-, moderate-, and high-contention scenarios.
  
  
• 6.1 Background
  
  
  • The example in section 6.1 shows that when two processes or threads attempt to write to the same location in memory concurrently, the outcome can be incorrect, even if the code executed by each individual thread is "error free."
    
    

    Time = 1	producer: register1 = counter	register1 == 5
    Time = 2	producer: register1 = register1 + 1	register1 == 6
    Time = 3	consumer: register2 = counter	register2 == 5
    Time = 4	consumer: register2 = register2 - 1	register2 == 4
    Time = 5	producer: counter = register1	counter == 6
    Time = 6	consumer: counter = register2	counter == 4

    
    
    
  • The example reminds us of these two essential facts:
    1. In the typical system an interrupt can arrive during the execution of any instruction, and
    2. After servicing an interrupt the OS is free to give the CPU to any thread that is ready.
    
    As a result there is potential for corruption of shared data due to the interleaved execution of instructions of different threads. (In the table above we see the instructions of the producer and consumer interleaved.)
    
    
  • The little example of the shared counter is not, of itself, very significant. However, operating systems programmers frequently need to solve similar problems. It is common for different parts of an OS to manipulate important data structures concurrently. Severe damage can be the result.
    
    
  • Often programmers take an approach to the problem like this: write each individual process so it is "correct" by itself, and synchronize the processes so that each one operates with exclusive access to the data at the "critical" times when a potential for error exists.
  
  
• 6.2 The Critical Section Problem
  
  
  • Suppose that a set {P₀, P₁, ..., P_n-1} of two or more processes share a datum D.
    
    Let the text sections (programs) of {P₀, P₁, ... , P_n-1} be {T₀, T₁, ... , T_n-1}
    
    
  • A programmer can designate certain sections of the T_i to be critical sections. The property that defines a critical section is this: "when one process is executing in its critical section, no other process is allowed to execute concurrently in its critical section."
    
    
  • A typical example would be to find sections of the T_i that write to D, and designate those sections of code as critical sections. (for example, the producer instruction that writes to the shared counter). If process X attempts to read D while process Y is writing to it, that can cause errors too. D could be in a transitional, inconsistent state. Therefore if any process might write D, normally all sections of code that access D (either to read or write) have to be designated as critical sections.
    
    
  • You have to keep in mind that the need for critical sections stems from the nature of the architecture of the computer. For example, it may conceivably be safe for a process to read a simple shared variable like a character or integer, even though another process might try to write the variable concurrently. If the hardware implements the operations used on the datum so that processes get exclusive access, then the operations are safe. In that case, they don't need to be protected with critical sections. (For example, when the Producer and Consumer read the value of the counter in their while-loop tests, those could be "atomic" load operations on simple integer variables.)
    
    
  • When we protect a datum D with critical sections, in all the T_i we place entry code before each critical section and exit code after each critical section.
    
    
  • A process executes the entry code to acquire the exclusive right to execute a critical section of code.
    
    
  • A process executes the exit code to release the exclusive right to execute a critical section of code.
    
    
  • So for example we would change the code of the producer and consumer like this:

    
    --------------------------------
    (producer code)
    
    while (true)
    {
      nextProduced=makeItem();
       /* while buffer full */
      while (count == BUFFER_SIZE) 
        ; /* do nothing */
      buffer[in] = nextProduced;
      in = (in+1) % BUFFER_SIZE;  
      ENTRY SECTION OF PRODUCER CODE;
      count++; 
      EXIT SECTION OF PRODUCER CODE;
    }
    
    --------------------------------
    (consumer code)
    
    while (true)
    {
        /* while buffer empty */
      while (count == 0) 
        ; /* do nothing */
      nextConsumed = buffer[out];
      out = (out+1) % BUFFER_SIZE; 
      ENTRY SECTION OF CONSUMER CODE;
      count--; 
      EXIT SECTION OF CONSUMER CODE;
      consume(nextConsumed);
    }
    
    

  • If the entry and exit code operate correctly then the producer cannot begin to change the counter while the consumer is in the act of changing the counter, and vice-versa. It is impossible for these portions of the producer and consumer to be interleaved, and so it is impossible for the counter to receive an incorrect value.
    
    
  • The "trick" is to design the entry and exit code so that it works the way it's supposed to work.
    
    
  • We want the entry and exit code to enforce exclusive access, but that's not really enough. The protocol implemented by the entry and exit code should be "fair" to the set of processes, and should allow them to operate as efficiently as possible.
    
    
  • The entry and exit code we create are called a solution to the critical section problem. A solution to the critical section problem must satisfy these requirements:
    
    
    1. Mutual Exclusion: If process P_i is executing in its critical section, then no other processes can be executing (concurrently) in their critical sections.
       
       
    2. Progress: If no process is executing in its critical section and some processes wish to enter their critical sections, then only those processes that are not executing in their remainder sections can participate in deciding which will enter its critical section next, and this selection cannot be postponed indefinitely.
       
       
    3. Bounded Waiting: There exists a bound, or limit, on the number of times that other processes are allowed to enter their critical sections after a process has made a request to enter its critical section and before that request is granted.
       
       
  • One thing to notice about these requirements is that the combination of the bounded waiting requirement and the progress requirement assures that each of the processes is free from starvation.
    
    
  • Notice also that the following is an equivalent way to state the Progress requirement:
    

         "If no process is executing in its critical section 
          and some processes wish to enter their critical sections, then 
          only processes executing entry code or exit code can participate 
          in deciding which will enter its critical section next,
          and this selection cannot be postponed indefinitely."

    The fact above is true because, by definition, all the code is either critical section, remainder section, entry code, or exit code.
    
    
  • To better understand the first part of the Progress Requirement, keep in mind that the kinds of solutions we are trying to describe here are ones that require the processes to "resolve their potential conflicts by working things out among themselves." The idea is that we put the protocol - the instructions for "working things out" - into the entry code and the exit code. When no process is in its critical section, the processes performing the protocol should be able to determine which process enters its critical section next. Furthermore, processes that are not executing the protocol should not be able to affect the decision.
    
    
  • (There are some situations in which a different approach to solving critical section problems is used. In that approach, we don't allow the processes to "resolve their potential conflicts by working things out among themselves." Instead we appoint a "governing process," or you could call it a "traffic cop" process, and put the governing process in charge of deciding which process can enter it's critical section next. Jobs like spooling print jobs are often done that way. The idea is that a process makes a request to the governor for access and then waits for the governor to grant its request. The governor decides which process to pick next. This approach is feasible and works well in some situations, but it is not feasible in a lot of situations. That's why we are examining the "work it out amongst yourselves" approach in this section of the course. )
    
    
  • Historical Note: Edsger Dijkstra did much of the early work on the critical section problem. Dijkstra died in 2002. He made many important and fundamental contributions to computer science. You can read about Dijkstra here:
    
    
    1. University of Texas CS Department Obituary of Dijkstra
    2. NY Times Obituary of Dijkstra
    3. University of Texas Information on Dijkstra (with links).
    
    
  • It is important to be aware that kernel code in an operating system may employ a special, privileged, technique for maintaining exclusive access to data. An OS can mask interrupts and refuse to relinquish its CPU while executing critical code. On a uniprocessor or asymmetric multiprocessor, this would assure the OS of exclusive access to the data. However, masking interrupts might also make the system unresponsive and/or prevent real-time processes from meeting deadlines. In the current era of symmetric multiprocessing and preemptive kernels, this "trick" of masking interrupts to assure exclusive access to data is often not feasible.
  
  
• 6.3 Peterson's Solution
  
  
  • Let's start out with a simplification: there are two processes P0 and P1.
    
    
  • The computer we are using is capable of performing atomic reads and writes to a simple integer or Boolean variable.
    
    
  • Algorithm 1: What if we try to solve the problem this way?
    
    (We use an infinite loop construct - think of it as a way to perform many trials of the synchronization code, or imagine that the processes are long-running servers that have to perform some particular set of actions over and over as long as the system is up.)

    
    [additional] shared variable: turn = 0; // Initialized to zero 
    --------------------------------
    (P0 code)
    
    do
    {
      while (turn != 0) //  Atomically test 'turn' 
         no-op; 
      critical section of P0 ; 
      turn = 1 ;   // Atomically write 'turn'  
      remainder section of P0
    } while (true) ;
    
    --------------------------------
    (P1 code)
    
    do
    {
      while (turn != 1) //  Atomically test 'turn' 
         no-op; 
      critical section of P1 ;
      turn = 0 ;   // Atomically write 'turn'  
      remainder section of P1
    } while (true) ;
    
    

  • Algorithm 1 satisfies the mutual exclusion and bounded waiting requirements, but violates the progress requirement.
    
    
  • Algorithm 2: What if we try to solve the problem this way?

    
    shared boolean flag[2]={false, false};
    -------------------------------
    (P0 code)
    
    do
    { 
      flag[0] = true ;
      while (flag[1]) 
        /* do nothing */ ; 
      critical section of P0 ; 
      flag[0]=false ; 
      remainder section of P0
    } while (true) ;
    
    --------------------------------
    (P1 code)
    
    do
    { 
      flag[1] = true ;
      while (flag[0]) 
        /* do nothing */ ; 
      critical section of P1 ; 
      flag[1]=false ; 
      remainder section of P1 ;
    } while (true) ;
    
    

  • Algorithm 2 gives us mutual exclusion but not conformance with the progress requirement. If we interchange the first two lines of the code of each process, we are assured progress, but not mutual exclusion.
    
    
  • Algorithm 3 (Peterson's algorithm): What if we try to solve the problem this way?

    
    shared boolean flag[2]={false, false};
    shared int turn = 0 ;
    --------------------------------
    (P0 code)
    
    do
    { 
      flag[0] = true ;
      turn = 1 ; 
      while (flag[1] && turn == 1) 
        /* do nothing */ ; 
      critical section of P0 ; 
      flag[0]=false ; 
      remainder section of P0
    } while (true) ;
    
    --------------------------------
    (P1 code)
    
    do
    {
      flag[1] = true ;
      turn = 0  
      while (flag[0] && turn == 0) 
        /* do nothing */ ; 
      critical section of P1 ; 
      flag[1]=false ; 
      remainder section of P1 ;
    } while (true) ;
    
    

  • Peterson's algorithm actually works.
    
    
    • If the processes set their flags at about the same time, then only one of them will win the race to set the value of turn. The loser will set the value of turn that allows the winner to drop out of the inner while-loop and enter its critical section (CS).
      
      
    • If P1 is in its remainder section and P0 tries to get into its CS, it will not be delayed because flag[1] will be false.
      
      
    • If P1 then tries to enter its CS while P0 is in its CS then P1 will be delayed because flag[0] will be true and turn will be zero.
      
      
    • Later when P0 leaves its CS it will set flag[0] to false. This will allow P1 to drop out of the inner while-loop and enter its CS.
      
      
    • Under these circumstances P0 cannot enter its CS again before P1 enters its CS. If P0 moves into its entry code immediately after exiting its CS, then P0 will be delayed in its inner while-loop because flag[1] will be true and turn will be 1.
  
  
• 6.4 Hardware Support for Synchronization
  
  
  • Basically Peterson's algorithm is correct. It is considered a "software solution" because the only dependency it has on the hardware is that simple load and store instructions are atomic. That means that if two processes attempt a simple load or store concurrently, the result will be the same as if one of the processes executes its instruction (entirely) first, and then the other executes its instruction (entirely) afterward.
    
    However, such algorithms have drawbacks. They are rather complex and difficult to understand. They do wasteful "busy waiting."
    
    Furthermore, a software solution can fail if the compiler or processor alters the order of execution of its instructions. That can happen in modern computing systems.
    
    
  • 6.4.1 Memory Barriers
    
    Many computer architectures have instructions called memory barriers or memory fences. They force memory changes to be propagated to all processors. Using memory fences, it is possible to prevent the type of alteration of execution order that could cause Peterson's algorithm (and other such algorithms) to fail.
    
    
  • 6.4.2 Hardware Instructions
    
    Let's try to develop something that has fewer disadvantages. One thing to notice is that we can get a simpler solution to the critical section problem if we have a "fancy" instruction implemented by the computer's hardware. Our text gives the examples of what can be done with an atomic test-and-set instruction or an atomic swap instruction.
    
    DEFINITION OF THE TestAndSet INSTRUCTION
    This must be implemented as an atomic operation.

    
    boolean TestAndSet(boolean *target)
    {
      boolean rv = *target; /* make copy */
      *target = true; /* set */
      return rv ; /* return copy */
    }

    Code as simple as this:

    ---------------------
    shared boolean locked=false;
    ---------------------
    do
    {
      while (TestAndSet(&locked)) 
        /* do nothing */ ;
      criticalSection(me) ;
      &locked = false ;
      remainderSection(me) ;
    } while(true) ;
    ---------------------
    

    implements mutual exclusion for a a set of n processes. (Each process P_i executes the code above with me == i.)
    
    We can satisfy all requirements for a solution to the critical section problem with code like this:

    ---------------------
    shared boolean waiting[n]={false,...,false};
    shared boolean locked = false;
    ---------------------
    
    void SolveCS(int me)
    {
      local int nextOne;
      do
      {
        waiting[me]=true;
        while( waiting[me] && TestAndSet(&locked) ) no-op ;
        waiting[me]=false;
    
        criticalSection(me) ;
    
        nextOne = (me + 1) % n ;
        while ( (nextOne != me) && (!waiting[nextOne]) )
           nextOne = (nextOne + 1) % n;
        if   (nextOne == me) locked = false
        else waiting[nextOne] = false ;
        
        remainderSection(me) ;
        
      } while(true) ;
    }
    ---------------------
    

  • 6.4.3 Atomic Variables
    
    There are many different kinds of tools used to solve synchronization problems. A common 'programming trick' is to use one type of synchronization tool to implement a different synchronization tool.
    
    In section 6.4.3, there's an example that discusses how to implement an atomic variable using an atomic compare_and_swap operation.
    
    An atomic variable X has the property that, unlike the counter variable discussed at the beginning of the chapter, a thread P can increment or decrement X without there being any possibility of another thread C being able to access X concurrently.
    
    
  • PROBLEM: All the solutions to synchronization problems that we have examined so far in this chapter require busy waiting. In other words they spin in loops, 'chewing up' CPU time while they wait their turn to enter their critical section of code. Depending on the circumstances, this can have a bad effect on system performance.
  
  
• 6.5 Mutex Locks
  
  
  • A mutex lock is a variable that supports two simple operations: acquire() and release(), which must be implemented atomically. Using a mutex, one can achieve mutual exclusion and progress (but not bounded waiting) with simple code like this:

      acquire lock // entry code
         do critical section 
      release lock  // exit code
         do remainder section

  • The following pseudo code defines what acquire() and release() do, but the pseudo code does not show how the two operations can be implemented so that they are atomic. As was mentioned earlier, it's often possible to implement one synchronization tool with another. It is relatively easy to implement mutexes by using an atomic test_and_set or compare_and_swap operation.

      acquire()
      {
         while (!available) 
            ; (busy wait)
         available = false;
      } 

      release()
      {
         available = true;
      } 

  • DEFINITION a thread busy waits when it waits for something while executing, (waiting while in the running state, instead of in the waiting state).
    
    
  • When a mutex lock is implemented by doing busy waiting, we call it a spinlock.
    
    
  • Under many circumstances, especially when locks are held for a long time on a uniprocessor, busy waiting wastes a significant amount of CPU cycles.
    
    
  • However, it requires the delay of two context switches if a thread changes to the waiting state (sleeps) to perform a wait. It takes one context switch to enter the waiting state, and one to enter the running state after the wait ends. Spinlocks have the advantage of not requiring those context switches, so systems often use spinlocks in situations where the wait is expected to take time less than two context switches. The typical situation in which spinlocks have the advantage is on a multiprocessor, when two threads are both executing on different CPUs, and one of them needs to wait for the other to release a lock.
  
  
• 6.6 Semaphores
  
  
  • A semaphore is a variable that supports two simple atomic operations: wait() and signal().
    
    
  • Semaphores are convenient for the programmer of critical section code. All the programmer has to do is use wait() for the entry code, and signal() for the exit code. It is all very simple-looking compared to Peterson's solution or the entry and exit code we've seen that uses TestAndSet().
    
    
  • For example, to guarantee that a thread T has exclusive access to the variable counter, T's program could declare a shared semaphore variable S, and then use code like this

              wait(S) ;
              counter++ ;
              signal(S) ;

    to assure exclusive access to counter while incrementing it.
    
    
  • Of course, the system designers have to implement wait() and signal() so that they are atomic operations.
    
    
  • 6.6.1 Semaphore Usage
    
    
    • There is a kind of semaphore, called a counting semaphore that provides some extra flexibility and functionality compared to mutexes or the more simple binary semaphores.
      
      There's also a special type of counting semaphore, called a queuing counting semaphore. When I describe ways to solve synchronization problems, I often show how to do it with queuing counting semaphores. When I say "semaphore," you should assume I'm referring to the queuing counting type unless I say otherwise.
      
      
    • We can use such semaphores to make nice, simple-looking solutions to critical section problems, and they have also proved to be useful for solving other kinds of process synchronization problems.
    
    
  • 6.6.2 Semaphore Implementation
    
    
    • To avoid excessive busy-waiting is an important design goal.
      
      The counting semaphore is a special data structure. The data part consists of an integer value and a list. The purpose of value is to function as a type of counter, and *Q is a list of threads. We will usually assume that *Q is implemented as a FIFO queue. The semaphore might be represented by this C-like declaration:

      
      typedef struct
      {
        int value ;
        struct process *Q ;
      } semaphore ;
      

      The semaphore data structure requires two operations, wait() and signal(), which must be implemented atomically. The following pseudo code describes what the operations do, but does not give any clue about how to implement the operations atomically:

      
      void wait(semaphore *S)
      {
        S->value--;
        if (S->value < 0)
        {
          add this process to S->Q;
          sleep() ;
        }
      }
      
      void signal(semaphore *S)
      {
        S->value++;
        if (S->value <= 0)
        {
          remove a process P from S->Q;
          wakeup(P);
        }
      }

      One can implement sleep() and wakeup(P) as system calls. A call to sleep() would suspend the calling process. The OS would get control of the CPU and put the process that called sleep() into a special sleep queue. The sleep queue is a data structure that the OS maintains. A process is not runnable while in the sleep queue. A call to wakeup(P) would cause the OS to get control of the CPU and to remove P from the sleep queue and return it to the ready queue.
      
      On a uniprocessor, one can implement wait() and signal() (without any busy waiting) as system calls. The OS can guarantee the atomic execution of wait() and signal() if it does two things while executing the code of wait() or signal():
      
      
      • refuse to relinquish the CPU, and
      • mask interrupts
        
        
      Under those circumstances nothing can "sneak in" and run in the CPU until after the wait() or signal() has completed.
      
      Unfortunately the method described above is hard to generalize to a multiprocessor platform. We would have to guarantee that no code running on any of the other CPU's would do anything to "conflict" with the critical section of code running the wait() or the signal().
      
      However on a multiprocessor, we could implement wait() and signal() using one of the software solutions we examined earlier in the chapter. For example, wait() could be implemented like this:

       /* Define the semaphore data type with some additional fields. */
      typedef struct
      {
        boolean waiting[n] ;
        boolean lock ;
        int value ;
        struct process *Q ;
      } semaphore ;
      
      void wait(semaphore *S, int me) 
      /* P.S. The second parameter would be hidden from the user */
      {
        boolean willSleep = false ;
        
      
           /* Entry Code for making wait() atomic */
        S->waiting[me] = true;
        while( S->waiting[me] && TestAndSet(S->lock) )  no-op ;
        S->waiting[me] = false;
      
               /*  Code that performs the wait operation */
        S->value--;
        if (S->value < 0)
        {
          add this process to S->Q;
          willSleep = true ;
        }
      
           /* Exit Code for making wait() atomic */
        int nextOne = (me+1)%n ;
        while ( (nextOne != me) && !S->waiting[nextOne] ) nextOne = (nextOne + 1) % n ;
        if (nextOne == me) 
        {
          if (willSleep) sleep(S->lock,false); /* Ask to sleep and have OS clear the lock. */
          else S->lock = false ; /* Clear the lock. */
        }
        else 
        {
          if (willSleep) sleep(S->waiting[nextOne], false); /*Ask to sleep & OS to clear flag.*/
          else S->waiting[nextOne] = false ; /* Clear the flag. */
        }
      }

      The pseudo-code above is just a very rough idea of what could be done.
      
      Note that the pseudo-code employs a modified version of the sleep() system call. The meaning of sleep(x,v) is "make the process sleep, and then set the variable x equal to the value v."
      
      Why use this form of sleep()?
      
      Basically it is due to a technical problem that comes up if a process P executing a wait() needs to sleep. In that case P needs to sleep and perform the exit code. Unfortunately no matter what order P tries to perform these actions, something can go wrong.
      
      If P sleeps it can't do anything next, so it can't execute the exit code. Consider that if P does not set one of the flags to false -- S->lock or S->waiting[nextOne] -- then none of the other processes using the semaphore will be able to perform a signal() or a wait(). All progress of the group of processes will stop. In particular, no process will ever wake P up.
      
      On the other hand it may not be acceptable for P to set one of the flags to false first and then sleep. The problem is that another process P' might execute a signal() and a wakeup(P) before P is able to sleep.
      
      Therefore, depending on exactly how wakeup() works on the system, P could "miss" its wakeup. P might wake up later when some other process executes a signal(), or it might never wake up. Either way, a lost wakeup can cause processes to malfunction.
      
      The solution idea we use here is to take the responsibility away from the process P and place it with the OS. The OS sets the flag to false after blocking P. However there is quite a range of different ways that wait() or signal() might be implemented, depending on what system calls the OS makes available, and also depending on what machine language instructions are available.
      
      Note that the solution we posed for the multiprocessor does require some busy waiting. However generally the amount of time spent doing this busy waiting will be negligible. There are only a few instructions involved in the wait and signal code, and processes do their busy waiting only when waiting to perform those short sequences of instructions.
      
      Contrast that with the case of such code as that below. Here some of the critical sections could be very long. There is the potential, for example, that one process, X, will execute a very long time in its critical section. It would be possible that several other processes could busy wait during all that time that X is in its critical section.

      
      void SolveCS(int me)
      {
        local int nextOne;
        do
        {
          waiting[me] = true;
          while( waiting[me] && TestAndSet(lock) ) no-op ;
          waiting[me] = false;
      
          criticalSection(me) ; /* could be very long */
      
          nextOne = (me+1) % n ;
          while ( (nextOne != me) && (!waiting[nextOne]) )
             nextOne = (nextOne+1) % n;
          if   (nextOne == me) lock = false
          else waiting[nextOne] = false ;
          
          remainderSection(me) ;
          
        } while(true) ;
      }

      In the version of the code below, implementing the wait and signal as described above for the multiprocessor case, the processes are blocked most of the time while waiting to enter their critical section. They only do busy waiting for a brief time while executing wait() and signal().
      
      As a result there is no significant busy waiting in this solution.

      
      ---------------------
      shared semaphore mutex ;
      ---------------------
      void SolveCS(int me)
      {
        do
        {
          wait (mutex) ;
          criticalSection(me) ; /* could be very long */
          signal (mutex) ;
          remainderSection(me) ;
        } while(true) ;
      }

  
  
• 6.7 Monitors
  
  
  • One may solve critical section problems, and many other types of synchronization problems, simply and easily through the use of semaphores.
    
    
  • However programmers can make mistakes when they try to code these problem solutions, leading to failures in mutual exclusion, progress, or bounded waiting.
    
    
  • 6.7.1 Monitor Usage
    
    Monitors are tools at a "level" somewhat higher than tools like semaphores.

    

    
    
    • Through the use of monitors the programmer can get a compiler's help in preventing coding errors.
      
      
    • The use of monitors is a form of object-oriented programming. A monitor is basically an object that is rigged so that only one process at a time can access the shared data inside the monitor. (The concept of a monitor dates back to the work of Brinch-Hansen in 1973. The idea of object-oriented computing dates from 1967 or earlier: [Simula 67, 1967, Dahl & Nygaard]).
      
      
    • The programmer writes code for the operations within the monitor (the methods). This is the only code than can access the (shared) data members of the monitor. The programmer also writes the client code, which is the code that makes calls to the operations inside the monitor.
      
      
    • The compiler takes care of, in effect, generating the entry code and exit code that guards the monitor so that only one process at a time can execute monitor code or access data inside the monitor.
      
      

      

      
      
    • For a programmer who needs to write a "tailor-made synchronization scheme," condition variables, which are similar to semaphores, may be declared inside the monitor.
      
      
  • 6.7.2 Implementing a Monitor Using Semaphores
    
    
    • This section contains some details on how a monitor can be implemented with semaphores. There will not be any test questions on these details.
      
      
    • However students are responsible for knowing that it is possible to implement monitors with semaphores.
      
      
  • 6.7.3 Resuming Processes within a Monitor
    
    
    • Mainly this section discussed the fact that the use of monitors does not 'magically' prevent programmer errors from happening. I will not ask test questions on the contents of the section.
      
      
    • This section also introduces the concept of a conditional-wait construct, which is a special kind of wait operation on a condition variable.
  
  
• 6.8 Liveness
  
  
  • The text defines liveness as properties of the system that ensure processes make progress. Liveness fails when processes are postponed indefinitely, or permanently.
    
    
  • Kinds of waiting:
    
    
    • A wait (aka a postponement) is bounded if, before the wait begins, there is a certain, specific limit on the maximum duration of the wait. For example, a wait that cannot last more than ten minutes is a bounded wait.
      
      
    • Indefinite postponement (aka starvation) is the opposite of bounded wait. It is a wait for which there is no certain, specific bound on its duration. If you buy lottery tickets each week, waiting to win a prize, you experience indefinite postponement.
      
      
    • Waiting forever for something (infinite postponement) is an extreme form of indefinite postponement. It's more than the lack of a bound on the wait. It is a wait that is sure never to end.
    
    
  • 6.8.1 Deadlock
    
    Deadlock is a form of infinite postponement that can occur in computing systems. Deadlock is the subject of Chapter 8, but the following example is offered as an introduction to the concept.

    ---------------------
      /* Declare two shared variables and 
         two shared semaphores, one to protect 
         each variable. Make 1 the initial value 
         of each semaphore. */
    
    shared int s_count, int q_count ;
    shared semaphore S, Q ; 
    ---------------------
    /* Code executed by P0: */
    
    wait(S)
    wait(Q)
     /* P0 accesses s_count and q_count */
      ...
    
    signal(Q)
    signal(S)
    ---------------------
    /* Code executed by P1: */
    
    wait(Q)
    wait(S)  // P1 waits in the opposite order.
      /* P1 accesses s_count and q_count */
      ...
    
    signal(S)
    signal(Q)
    ---------------------

    Suppose that the actions of P0 and P1 are interleaved in the following way. P0 first executes wait(S). Now S->value == 0. Next P1 executes wait(Q). Now Q->value == 0. Next P0 executes wait(Q). This causes Q->value to become -1, and it also causes P0 to be blocked and queued on Q->list. Next P1 executes wait(S). Now S->value == -1 and P1 is blocked, waiting in S->list.
    
    According to the semantics of the program, P0 and P1 will now wait forever. P0 will continue to wait for P1 to perform the signal(Q) instruction, and P1 will continue to wait for P0 to execute the signal(S) instruction.
    
    
  • 6.8.2 Priority Inversion
    
    A high priority process H may have to wait excessively long for a resource held by a low priority process L. The problem can be especially bad if a long succession of processes M_i with priority in between L and H, come along and prevent L from executing.
    
    Modern operating systems are designed to use a technique called priority inheritance in cases like this. During the time that L holds the resource needed by H, it would run with the same priority as H. That way L would not be preempted by processes like the M_i, and so it would have a better chance to finish with the resource quickly, so that it would become available to H.
    
    Incidentally, the inset on page 285 of the paper text describes how this exact kind of problem nearly caused a failure of the 1997 Mars Pathfinder mission.
  
  
• 6.9 Evaluation
  
  This section discusses a variety of tools used for process synchronization, and some of the advantages and disadvantages of each. It's an interesting read. However, I don't intend to test the class on that information.