1 / 57

Chapter 5 Concurrency: Mutual Exclusion and Synchronization

Chapter 5 Concurrency: Mutual Exclusion and Synchronization. Operating Systems: Internals and Design Principles. Seventh Edition By William Stallings.

kaili
Download Presentation

Chapter 5 Concurrency: Mutual Exclusion and Synchronization

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. Chapter 5Concurrency: Mutual Exclusion and Synchronization Operating Systems:Internals and Design Principles Seventh Edition By William Stallings

  2. “ Designing correct routines for controlling concurrent activities proved to be one of the most difficult aspects of systems programming. The ad hoc techniques used by programmers of early multiprogramming and real-time systems were always vulnerable to subtle programming errors whose effects could be observed only when certain relatively rare sequences of actions occurred. The errors are particularly difficult to locate, since the precise conditions under which they appear are very hard to reproduce.” —THE COMPUTER SCIENCE AND ENGINEERING RESEARCH STUDY, MIT Press, 1980 Operating Systems:Internals and Design Principles

  3. Multiple Processes • Operating System design is concerned with the management of processes and threads: • Multiprogramming • Multiprocessing • Distributed Processing

  4. ConcurrencyArises in Three Different Contexts:

  5. Principles of Concurrency • Interleaving and overlapping • can be viewed as examples of concurrent processing • both present the same problems • Uniprocessor – the relative speed of execution of processes cannot be predicted • depends on activities of other processes • the way the OS handles interrupts • scheduling policies of the OS

  6. Difficulties of Concurrency • Sharing of global resources • Difficult for the OS to manage the allocation of resources optimally • Difficult to locate programming errors as results are not deterministic and reproducible

  7. Race Condition • Occurs when multiple processes or threads read and write data items • The final result depends on the order of execution • the “loser” of the race is the process that updates last and will determine the final value of the variable

  8. Race Condition (Example 1) • Two processes share the global variable a • P1 and P2, • At some point in its execution, • P1 updates a to the value 1, • P2 updates a to the value 2. • Thus, the two tasks are in a race to write variable a . • Results • the “loser” of the race (the process that updates last) determines the final value of a .

  9. Race Condition (Example 2) • Two processes share the global variable b, c • P3 and P4, • b = 1 and c = 2 . • At some point in its execution, • P3: b= b + c • P4: c = b + c . • Results • If P3 executes first, • b = 3 and c = 5 . • If P4 executes first, • b = 4 and c = 3 .

  10. Operating System Concerns • Design and management issues raised by the existence of concurrency: • The OS must: • be able to keep track of various processes • allocate and de-allocate resources for each active process • protect the data and physical resources of each process against interference by other processes • ensure that the processes and outputs are independent of the processing speed

  11. Resource Competition • Concurrent processes come into conflict when they are competing for use of the same resource • for example: I/O devices, memory, processor time, clock

  12. Mutual Exclusion Figure 5.1 Illustration of Mutual Exclusion

  13. The enforcement of mutual exclusion creates two additional control problems. • deadlock . • P1 and P2, and two resources, R1 and R2. • Suppose that each process needs access to both resources to perform part of its function. • Situation: R1 to P2, and R2 to P1. • Each process is waiting for one of the two resources. • Neither will release the resource that it already owns until it has acquired the other resource and performed the function requiring both resources. • starvation . P1, P2, P3 each require periodic access to resource R. • Situation • P1 has R, and both P2 and P3 waiting for R. • When P1 exits its critical section, P3 access to R. • When P3 exits its critical section, P1 access to R. • P2 may indefinitely be denied access to the resource, even though there is no deadlock situation.

  14. Requirements for Mutual Exclusion • Must be enforced • A process that halts must do so without interfering with other processes • No deadlock or starvation • A process must not be denied access to a critical section when there is no other process using it • No assumptions are made about relative process speeds or number of processes • A process remains inside its critical section for a finite time only

  15. CommonConcurrency Mechanisms

  16. Semaphore • May be initialized to a nonnegative integer value • The semWait operation decrements the value • The semSignal operation increments the value

  17. Semaphore Principle • Two or more processes can cooperate by means of simple signals • a process can be forced to stop at a specified place until it has received a specific signal. • For signaling, special variables called semaphores are used. • To transmit a signal via semaphore s , a process executes the primitive semSignal(s) . • To receive a signal via semaphore s , a process executes the primitive semWait(s) ; • if the corresponding signal has not yet been transmitted, the process is suspended until the transmission takes place.

  18. Consequences

  19. Semaphore Primitives

  20. How Semaphore works? • To begin, the semaphore has a zero or positive value (e.g., 5). • semWait is called 5 times • 5 processes that can issue a wait and immediately continue to execute. • If the value is zero, either by initialization or because a number of processes equal to the initial semaphore value have issued a wait, the next process to issue a wait is blocked, and the semaphore value goes negative. • Each subsequent wait drives the semaphore value further into minus territory. • The negative value equals the number of processes waiting to be unblocked. • Each signal unblocks one of the waiting processes (In the queue) when the semaphore value is negative.

  21. Binary Semaphore Primitives

  22. Strong/Weak Semaphores • A queue is used to hold processes waiting on the semaphore

  23. Example of Semaphore Mechanism

  24. Mutual Exclusion

  25. Shared Data Protected by a Semaphore

  26. Producer/Consumer Problem

  27. Buffer Structure

  28. n = in – out : keep track of the number of items in the buffer, using the integer variable • The semaphore s is used to enforce mutual exclusion; • The semaphore n # of item

  29. Finite Circular Buffer

  30. Solution Using Semaphores Figure 5.13 A Solution to the Bounded-Buffer Producer/Consumer Problem Using Semaphores

  31. Monitors • Programming language construct that provides equivalent functionality to that of semaphores and is easier to control • Implemented in a number of programming languages • including Concurrent Pascal, Pascal-Plus, Modula-2, Modula-3, and Java • Has also been implemented as a program library • Software module consisting of one or more procedures, an initialization sequence, and local data

  32. Monitor Characteristics

  33. Synchronization • Achieved by the use of condition variables that are contained within the monitor and accessible only within the monitor • Condition variables are operated on by two functions: • cwait(c): suspend execution of the calling process on condition c • csignal(c): resume execution of some process blocked after a cwait on the same condition

  34. Structure of a Monitor Figure 5.15 Structure of a Monitor

  35. Problem Solution Using a Monitor Figure 5.16 A Solution to the Bounded-Buffer Producer/Consumer Problem Using a Monitor

  36. Message Passing • When processes interact with one another two fundamental requirements must be satisfied: • Message Passing is one approach to providing both of these functions • works with distributed systems and shared memory multiprocessor and uniprocessor systems

  37. Message Passing • The actual function is normally provided in the form of a pair of primitives: send (destination, message) receive (source, message) • A process sends information in the form of a message to another process designated by a destination • A process receives information by executing the receive primitive, indicating the source and the message

  38. Message Passing Table 5.5 Design Characteristics of Message Systems for Interprocess Communication and Synchronization

  39. Synchronization

  40. Blocking Send, Blocking Receive Both sender and receiver are blocked until the message is delivered Sometimes referred to as a rendezvous Allows for tight synchronization between processes

  41. Nonblocking Send

  42. Addressing • Schemes for specifying processes in send and receive primitives fall into two categories:

  43. Direct Addressing • Send primitive includes a specific identifier of the destination process • Receive primitive can be handled in one of two ways: • require that the process explicitly designate a sending process • effective for cooperating concurrent processes • implicit addressing • source parameter of the receive primitive possesses a value returned when the receive operation has been performed

  44. Indirect Addressing

  45. Indirect Process Communication

  46. General Message Format

  47. Mutual Exclusion

More Related