Monitors

• Although semaphores provide a convenient and effective mechanism for process synchronization, using them incorrectly can result in timing errors that are difficult to detect, since these errors happen only if some particular execution sequences take place and these sequences do not always occur.
• The semaphore solution to the CS problem.
  • All processes share a semaphore variable $mutex$, which is initialized to 1.
  • Each process must execute $wait(mutex)$ before entering the CS and $signal(mutex)$ afterward.
  • If this sequence is not observed,two processes may be in their CSs simultaneously.
• Suppose that a process interchanges the order in which the $wait()$ and $signal()$ operations on the semaphore mutex are executed, resulting in the following execution:

  signal(mutex);
      ...
   critical section
      ...
  wait(mutex);
  

  • In this situation, several processes maybe executing in their CSs simultaneously, violating the mutual-exclusion requirement.
  • This error may be discovered only if several processes are simultaneously active in their CSs. Note that this situation may not always be reproducible.
• Suppose that a process replaces $signal(mutex)$ with $wait(mutex)$. That is, it executes

  wait(mutex);
      ...
   critical section
      ...
  wait(mutex);
  

  In this case, a deadlock will occur.
• Suppose that a process omits the $wait(mutex)$, or the $signal(mutex)$, or both. In this case, either mutual exclusion is violated or a deadlock will occur.
• These examples illustrate that various types of errors can be generated easily when programmers use semaphores incorrectly to solve the CS problem.
• You must be careful when using semaphores. It is like programming in assembly language, only worse, because the errors are race conditions, deadlocks, and other forms of unpredictable and irreproducible behavior.
• Semaphores require programmer to think of every timing issue; easy to miss something, difficult to debug. Let the compiler handle the details. Programmer only has to say what to protect.
• Researchers have developed high-level language constructs - monitor.
  • A monitor is a collection of procedures, variables, and data structures that are all grouped together in a special kind of module or package.
  • Processes may call the procedures in a monitor whenever they want to, but they cannot directly access the monitor's internal data structures from procedures declared outside the monitor.
• Monitors have an important property that makes them useful for achieving mutual exclusion: only one process can be active in a monitor at any instant.
• Monitors are a programming language construct, so the compiler knows they are special and can handle calls to monitor procedures differently from other procedure calls.
• Compiler actually does the protection (compiler will use semaphores to do protection).
• Main problem: provides less control.
• Some real programming languages also support monitors. One such language is Java.
• Java is an object-oriented language that supports user-level threads and also allows methods (procedures) to be grouped together into classes.
• By adding the keyword synchronized to a method declaration, Java guarantees that once any thread has started executing that method, no other thread will be allowed to start executing any other synchronized method in that class.