1 / 27

Operating Systems

Learn about the critical-section problem in cooperating processes, and discover solutions that ensure mutual exclusion, progress, and bounded waiting. Explore different software, hardware, operating system, and programming language solutions.

fiecke
Download Presentation

Operating Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Operating Systems The Critical-Section Problem A. Frank - P. Weisberg

  2. Cooperating Processes • Introduction to Cooperating Processes • Producer/Consumer Problem • The Critical-Section Problem • Synchronization Hardware • Semaphores A. Frank - P. Weisberg

  3. The Critical-Section Problem • n processes competing to use some shared data. • No assumptions may be made about speeds or the number of CPUs. • Each process has a code segment, called Critical Section (CS), in which the shared data is accessed. • Problem – ensure that when one process is executing in its CS, no other process is allowed to execute in its CS. A. Frank - P. Weisberg

  4. CS Problem Dynamics (1) • When a process executes code that manipulates shared data (or resource), we say that the process is in it’s Critical Section (for that shared data). • The execution of critical sections must be mutually exclusive:at any time, only one process is allowed to execute in its critical section (even with multiple processors). • So each process must first request permission to enter its critical section. A. Frank - P. Weisberg

  5. CS Problem Dynamics (2) • The section of code implementing this request is called the Entry Section (ES). • The critical section (CS) might be followed by a Leave/Exit Section (LS). • The remaining code is the Remainder Section (RS). • The critical section problem is to design a protocol that the processes can use so that their action will not depend on the order in which their execution is interleaved (possibly on many processors). A. Frank - P. Weisberg

  6. General structure of process Pi(other is Pj) do { entry section critical section leave section remainder section } while (TRUE); • Processes may share some common variables to synchronize their actions. A. Frank - P. Weisberg

  7. Solution to Critical-Section Problem • There are 3 requirements that must stand for a correct solution: • Mutual Exclusion • Progress • Bounded Waiting • We can check on all three requirements in each proposed solution, even though the non-existence of each one of them is enough for an incorrect solution. A. Frank - P. Weisberg

  8. Solution to CS Problem – Mutual Exclusion • Mutual Exclusion – If process Pi is executing in its critical section, then no other processes can be executing in their critical sections. • Implications: • Critical sections better be focused and short. • Better not get into an infinite loop in there. • If a process somehow halts/waits in its critical section, it must not interfere with other processes. A. Frank - P. Weisberg

  9. Solution to CS Problem – Progress • Progress – If no process is executing in its critical section and there exist some processes that wish to enter their critical section, then the selection of the process that will enter the critical section next cannot be postponed indefinitely: • If only one process wants to enter, it should be able to. • If two or more want to enter, one of them should succeed. A. Frank - P. Weisberg

  10. Solution to CS Problem – Bounded Waiting • Bounded Waiting – A bound must exist 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. • Assume that each process executes at a nonzero speed. • No assumption concerning relative speed of the n processes. A. Frank - P. Weisberg

  11. Types of solutions to CS problem • Software solutions – • algorithms who’s correctness does not rely on any other assumptions. • Hardware solutions – • rely on some special machine instructions. • Operating System solutions – • provide some functions and data structures to the programmer through system/library calls. • Programming Language solutions – • Linguistic constructs provided as part of a language. A. Frank - P. Weisberg

  12. Software Solutions • We consider first the case of 2 processes: • Algorithm 1 and 2 are incorrect. • Algorithm 3 is correct (Peterson’s algorithm). • Then we generalize to n processes: • The Bakery algorithm. • Initial notation: • Only 2 processes, P0 and P1 • When usually just presenting process Pi (Larry, I, i), Pj (Jim, J, j) always denotes other process (i != j). A. Frank - P. Weisberg

  13. Initial Attempts to Solve Problem • General structure of process Pi(other is Pj) – do { entry section critical section leave section remainder section } while (TRUE); • Processes may share some common variables to synchronize their actions. A. Frank - P. Weisberg

  14. Algorithm 1 – Larry/Jim version • Shared variables: • string turn; initially turn = “Larry” or “Jim” (no matter) • turn = “Larry” Larry can enter its critical section • Process Larry do { while (turn != “Larry”); critical section turn = “Jim”; remainder section } while (TRUE); • Jim’s version is similar but “Larry”/“Jim” reversed. A. Frank - P. Weisberg

  15. Algorithm 1 – Pi/Pj version • Shared variables: • int turn; initially turn = 0 • turn = i Pi can enter its critical section • Process Pi do { while (turn != i); critical section turn = j; remainder section } while (TRUE); • Satisfies mutual exclusion and bounded waiting, but not progress. A. Frank - P. Weisberg

  16. Why Algorithm 1 fails • P0 has entered the critical section, finished it, and set the turn to P1. • P1 enters the section, completes it, sets the turn back to P0. • P1 quickly completes the remainder section, and wishes to enter the critical section again. However, P0 still holds the turn. • P0 gets stalled somewhere in its remainder section indefinitely. P1 is starved. A. Frank - P. Weisberg

  17. Algorithm 2 – Larry/Jim version • Shared variables • boolean flag-larry, flag-jim; initially flag-larry = flag-jim = FALSE • flag-larry= TRUE Larry ready to enter its critical section • Process Larry do { flag-larry = TRUE; while (flag-jim); critical section flag-larry = FALSE; remainder section } while (TRUE); A. Frank - P. Weisberg

  18. Algorithm 2 – Pi/Pj version • Shared variables • boolean flag[2]; initially flag [0] = flag [1] = FALSE • flag [i] = TRUE Pi wants to enter its critical section • Process Pi do { flag[i] = TRUE; while (flag[j]); critical section flag [i] = FALSE; remainder section } while (TRUE); • Satisfies mutual exclusion, but not progress and bounded waiting (?) requirements. A. Frank - P. Weisberg

  19. Why Algorithm 2 fails • Satisfies mutual exclusion, but not progress requirement. – • Both processes can end up setting their flag[] variable to true, and thus neither process enters its critical section! A. Frank - P. Weisberg

  20. Algorithm 4 – Larry/Jim version • Combined shared variables of algorithms 1 and 2/3. • Process Larry do { flag-larry = TRUE; turn = “Jim”; while (flag-jim and turn == “Jim”); critical section flag-larry = FALSE; remainder section } while (TRUE); A. Frank - P. Weisberg

  21. Algorithm 4 – Pi/Pj version • Combined shared variables of algorithms 1 and 2/3. • Process Pi do { flag [i] = TRUE; turn = j; while (flag [j] and turn == j); critical section flag [i] = FALSE; remainder section } while (TRUE); • Meets all three requirements; solves the critical-section problem for two processes. A. Frank - P. Weisberg

  22. Algorithm 5 – Larry/Jim version • Like Algorithm 4, but with the first 2 instructions of the entry section swapped – is it still a correct solution? • Process Larry do { turn = “Jim”;flag-larry = TRUE; while (flag-jim and turn == “Jim”); critical section flag-larry = FALSE; remainder section } while (TRUE); A. Frank - P. Weisberg

  23. Bakery Algorithm (1) • Critical Section for n processes: • Before entering its critical section, a process receives a number (like in a bakery). Holder of the smallest number enters the critical section. • The numbering scheme here always generates numbers in increasing order of enumeration; i.e., 1,2,3,3,3,3,4,5... • If processes Pi and Pj receive the same number, if i < j, then Pi is served first; else Pj is served first (PID assumed unique). A. Frank - P. Weisberg

  24. Bakery Algorithm (2) • Choosing a number: • max (a0,…, an-1) is a number k, such that k ai for i = 0, …, n – 1 • Notation for lexicographical order (ticket #, PID #) • (a,b) < (c,d) if a < c or if a == c and b < d • Shared data: boolean choosing[n]; int number[n]; Data structures are initialized to FALSE and 0, respectively. A. Frank - P. Weisberg

  25. Bakery Algorithm for Pi do { choosing[i] = TRUE; number[i] = max(number[0], …, number[n – 1]) +1; choosing[i] = FALSE; for (j = 0; j < n; j++) { while (choosing[j]) ; while ((number[j] != 0) && ((number[j],j) < (number[i],i))) ; } critical section number[i] = 0; remainder section } while (TRUE); A. Frank - P. Weisberg

  26. What about process failures? • If all 3 criteria (ME, progress, bounded waiting) are satisfied, then a valid solution will provide robustness against failure of a process in its remainder section (RS). • since failure in RS is just like having an infinitely long RS. • However, no valid solution can provide robustness against a process failing in its critical section (CS). • A process Pi that fails in its CS does not signal that fact to other processes: for them Pi is still in its CS. A. Frank - P. Weisberg

  27. Drawbacks of software solutions • Software solutions are very delicate . • Processes that are requesting to enter their critical section are busy waiting (consuming processor time needlessly). • If critical sections are long, it would be more efficient to block processes that are waiting. A. Frank - P. Weisberg

More Related