Answers.Body: <p>One reason infinite loops are used could be so the problem can't be solved by letting one thread complete the code before the other thread starts it. With infinite loops, no thread ever completes the code. Of course, using a bounded buffer has the same effect.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-06-08T16:47:57.710Z
Answers.LastActivityDate: 2017-06-08T16:47:57.710Z
Answers.UserDisplayName: Ellen Spertus
Answers.Body: <p>"processes that run and enter critical sections ... where the code is not in an infinite loop"</p>
  
  <p>Processes are generally components of a reactive system (like an OS) that are designed to be non-terminating (hopefully, otherwise we call it a "crash"!). So even if the code of the process doesn't contain an infinite loop, the process will be invoked an indefinite number of times (a better term to use than "infinite loop").</p>
  
  <p>You could give the example of your students' phones: Android and iOS are non-terminating, until you switch the phone off or the battery becomes empty. You don't expect Facebook to terminate so you can waste as much time as you like scrolling through posts :-).</p>
  
  <p>A better explanation may be somewhat technical. Ask what the specification of the program is. For a terminating program, the specification is functional: the precondition is (say) x>=0 and the postcondition is y=sqrt(x). For critical sections, the specification is in terms of (1) invariants: <em>always</em> at most one job is being printer on an individual printer, (2) liveness conditions: if a job is ready, <em>eventually</em> it will be printed.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-06-09T15:34:32.080Z
Answers.LastActivityDate: 2017-06-09T15:34:32.080Z
Answers.UserDisplayName: Moti
Body: <p>I've noticed that "all" OS textbooks present the Critical-Section Problem with examples of code that are in infinite loops.  E.g.,</p>
  
  <pre><code>while (true) {
      // code here to do the entry section protocol
  
      // critical section here
  
      // code here to do the exit section protocol
  
      // remainder section
  }
  </code></pre>
  
  <p>Why is this?  From my experience there can be many processes that run and enter critical sections (inspecting and updating shared variables) where the code is not in an infinite loop.  This business of always have code in loops seem to unnecessarily complicate matters for students.</p>
  
  <p>Is there something I'm just not understanding about this concept?</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-06-08T17:54:51.893Z
Comments.Text: Could it be that, at the OS level, the thread protecting the shared resource should never quit? For example, as long as the print spool is running, each process must be allowed to complete its print before another starts, but the spool is always protected by the critical section loop, even if nothing is being spooled. The protective loop will only terminate when its thread is killed externally, such as the OS removing that print spool.
Comments.UserDisplayName: Gypsy Spellweaver
Tags: <concurrency><operating-systems>
Title: Why is the critical-section problem always presented with code in infinite loops?
ThreadText: # Why is the critical-section problem always presented with code in infinite loops?
  
  (Asked by: username_0 on 2017-06-08)
  
  I've noticed that "all" OS textbooks present the Critical-Section Problem with examples of code that are in infinite loops. E.g.,
  
  ```
  while (true) {
      // code here to do the entry section protocol
  
      // critical section here
  
      // code here to do the exit section protocol
  
      // remainder section
  }
  
  ```
  
  Why is this? From my experience there can be many processes that run and enter critical sections (inspecting and updating shared variables) where the code is not in an infinite loop. This business of always have code in loops seem to unnecessarily complicate matters for students.
  
  Is there something I'm just not understanding about this concept?
  
  **Tags:** concurrency, operating-systems
  
  > **Comments:**
  > **username_1**: Could it be that, at the OS level, the thread protecting the shared resource should never quit? For example, as long as the print spool is running, each process must be allowed to complete its print before another starts, but the spool is always protected by the critical section loop, even if nothing is being spooled. The protective loop will only terminate when its thread is killed externally, such as the OS removing that print spool.  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_2 on 2017-06-08. Score: 9 | Accepted answer
  
  One reason infinite loops are used could be so the problem can't be solved by letting one thread complete the code before the other thread starts it. With infinite loops, no thread ever completes the code. Of course, using a bounded buffer has the same effect.
  
  
  ---
  
  ### Answer by username_3 on 2017-06-09. Score: 5
  
  "processes that run and enter critical sections ... where the code is not in an infinite loop"
  
  Processes are generally components of a reactive system (like an OS) that are designed to be non-terminating (hopefully, otherwise we call it a "crash"!). So even if the code of the process doesn't contain an infinite loop, the process will be invoked an indefinite number of times (a better term to use than "infinite loop").
  
  You could give the example of your students' phones: Android and iOS are non-terminating, until you switch the phone off or the battery becomes empty. You don't expect Facebook to terminate so you can waste as much time as you like scrolling through posts :-).
  
  A better explanation may be somewhat technical. Ask what the specification of the program is. For a terminating program, the specification is functional: the precondition is (say) x>=0 and the postcondition is y=sqrt(x). For critical sections, the specification is in terms of (1) invariants: *always* at most one job is being printer on an individual printer, (2) liveness conditions: if a job is ready, *eventually* it will be printed.
  
  
  ---
  
  