1 / 65

Concurrency: Mutual Exclusion and Synchronization

Concurrency: Mutual Exclusion and Synchronization. Chapter 5. Concurrency. Characteristics of concurrent / interleaved processes: share/compete for resources communicate synchronize their activities. Concurrency. Same problems in multiprogramming and multiprocessing

gin
Download Presentation

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. Concurrency: Mutual Exclusion and Synchronization Chapter 5

  2. Concurrency • Characteristics of concurrent / interleaved processes: • share/compete for resources • communicate • synchronize their activities

  3. Concurrency • Same problems in multiprogramming and multiprocessing • Basic method to support concurrency • mutual exclusion: • the ability to exclude all other processes from a course of action while one process is engaged in that action

  4. A Simple Example void echo() { chin = getchar(); chout = chin; putchar(chout); }

  5. ‘one processor’ case The echo procedure and its variables are shared by two processes P1 and P2 P1: chin = getchar();// user types ‘x’ interrupted, chin contains ‘x’ P2: chin = getchar();// user types ‘y’ chout = chin; putchar(chout);// ‘y’ is displayed interrupted, chin contains ‘y’ P1: chout = chin; putchar(chout);// ‘y’ is displayed instead of ‘x’

  6. ‘two-processors’ case Process P1 Process P2 . . in = getchar(); . . in = getchar(); chout = chin; chout = chin; putchar(chout); . . putchar(chout); . .

  7. Operating System Concerns • Keep track of active processes • Allocate and deallocate resources • Processor time • Memory • Files • I/O devices • Protect data and resources • Result of process must be independent of the speed of execution of other concurrent processes

  8. Process Interaction • Processes unaware of each other • Independent • competition for resources • Processes indirectly aware of each other • share access to some object • cooperation • data coherence problem • Process directly aware of each other • work jointly on some activity • communicate via messages to coordinate activities • cooperation

  9. Control problems • Mutual exclusion • Two processes require access to a single non-shareable resource. • Critical resource - the resource in question. • Critical section in the program - the portion in the program that uses the resource • The rule: only one program at a time be allowed in its critical section

  10. Deadlock • Deadlock • Involves at least two processes • P1 waits for an event to be produced by P2 • P2 waits for an event to be produced by P1

  11. Starvation • Starvation • Involves at least three processes P1, P2, P3, competing for non-shareable resource • P1 and P2 alternatively use the resource • P3 may indefinitely be denied access to that resource.

  12. Competition Among Processes for Resources • Mutual Exclusion • Critical sections • Only one program at a time is allowed in its critical section • Example only one process at a time is allowed to send command to the printer • Deadlock • Starvation

  13. Cooperation Among Processes by Sharing • Writing must be mutually exclusive • Critical sections are used to provide data integrity

  14. Cooperation Among Processes by Communication • Messages • Mutual exclusion is not a control requirement • Possible to have deadlock • Each process waiting for a message from the other process • Possible to have starvation • Two processes sending message to each other while another process waits for a message

  15. Requirements for Mutual Exclusion • Only one process at a time is allowed in the critical section for a resource • A process that halts in its non-critical section must do so without interfering with other processes • No deadlock or starvation • Grant 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

  16. Mutual Exclusion - software approaches First attempt Processes P0 and P1, global variable turn If turn = 0, P0 can enter its critical section If turn = 1, P1 can enter its critical section while (turn != 0) /* do nothing */ ; /* critical section */; turn = 1;

  17. First attempt • Each process enters its critical section and then transfers the access (by changing the value of turn) to the other process. • busy waiting- while waiting to enter the critical section the process repeatedly checks the status of its permission (reads the value of turn) • guarantees mutual exclusion • Drawbacks • processes must strictly alternate reducing the speed of execution • if one process fails the other is permanently blocked.

  18. Second attempt • Using a separate variable for each process whose contents determine whether a process is in use of its critical section or not • while (flag[1]) • /* do nothing */ ; • flag[0] = true; • /* critical section */; • flag[0] = false; • No mutual exclusion however, due to the possibility of interleaving the operations for status checking and status changing

  19. Third Attempt • Set flag to enter critical section before checking other processes • flag[0] = true; • while (flag[1]) • /* do nothing */ ; • /* critical section */; • flag[0] = false;

  20. Third Attempt • If another process is in the critical section when the flag is set, the process is blocked until the other process releases the critical section • Deadlock is possible when two process set their flags to enter the critical section. Now each process must wait for the other process to release the critical section

  21. Fourth Attempt • A process sets its flag to indicate its desire to enter its critical section but is prepared to reset the flag • flag[0] = true; • while (flag[1]) • { flag[0] = false; • /* delay */ ; • flag[0] = true; } • /* critical section */; • flag[0] = false;.

  22. Fourth Attempt • This is not working due to the possibility of interleaving the operations for status changing and status checking. • There is a situation when none of the processes would be able to enter its critical section, similar to the situations described above.

  23. Correct Solution • Each process gets a turn at the critical section • If a process wants the critical section, it sets its flag and may have to wait for its turn

  24. Dekker’s algorithm flag[0] = true; //indicate the need to enter // critical section while (flag[1]) //while the other process is // also entering if (turn == 1) // if it is its turn { flag[0] = false; //reset the flag to false while (turn == 1) // wait while it is still // its turn /* do nothing */ ; flag[0] = true; //indicate entering the // critical section } /* critical section */; turn = 1; //give the turn to the other process flag [0] = false; //change status

  25. Peterson’s algorithm flag[0] = true; //indicate the need to // enter critical section turn = 1; //grant the turn to the // other process while (flag[1] && turn == 1) //mutual exclusion /* do nothing */ /* critical section */; flag [0] = false; //change status

  26. Mutual Exclusion:Hardware Support • Interrupt Disabling • Disabling interrupts guarantees mutual exclusion • Processor is limited in its ability to interleave programs • Multiprocessing • disabling interrupts on one processor will not guarantee mutual exclusion

  27. Mutual Exclusion:Hardware Support • Special Machine Instructions • Performed in a single instruction cycle • Not subject to interference from other instructions • Reading and writing • Reading and testing

  28. Mutual Exclusion Machine Instructions • Advantages • Applicable to any number of processes on either a single processor or multiple processors sharing main memory • It is simple and therefore easy to verify • It can be used to support multiple critical sections

  29. Mutual Exclusion Machine Instructions • Disadvantages • Busy-waiting consumes processor time • Starvation is possible when a process leaves a critical section and more than one process is waiting. • Deadlock • If a low priority process has the critical region and a higher priority process needs, the higher priority process will obtain the processor to wait for the critical region

  30. Semaphores • The setting: • Special variable called a semaphore is used for signaling • If a process is waiting for a signal, it is suspended until that signal is sent • Wait and signal operations cannot be interrupted • Queue is used to hold processes waiting on the semaphore

  31. Semaphores • Semaphore is a variable that has an integer value • May be initialized to a nonnegative number • Wait operation decrements the semaphore value • Signal operation increments semaphore value

  32. Semaphore types • Binary semaphore - binary values 0 and 1. • Strong semaphore - a semaphore whose definition includes the policy of first-in-first-out (FIFO) queue. • Weak semaphore - a semaphore that does not specify the order in which processes are removed from the queue. • Strong semaphores guarantee avoiding starvation.

  33. Example: Barbershop Problem

  34. Mutual exclusion with semaphores Each process performs: wait(s); /* critical section */ signal(s);

  35. Producer/Consumer Problem • One or more producers are generating data and placing these in a buffer • A single consumer is taking items out of the buffer one at time • Only one producer or consumer may access the buffer at any one time

  36. Producer/Consumer ProblemInfinite Buffer

  37. Circular Buffer

  38. Producer producer: while (true) { /* produce item v */ b[in] = v; in++; }

  39. Consumer consumer: while (true) { while (in <= out) /*do nothing */; w = b[out]; out++; /* consume item w */ }

  40. Producer/Consumer Problem • the consumer takes an item only if one is available • a semaphore that prevents the consumer from reading when the buffer is empty (n = out - in) • mutual exclusion is not ensured • solution: • a semaphore that allows only one producer/consumer to perform write/read

  41. Producer/Consumer Problem s - semaphore for entering the critical section delay - semaphore to ensure reading from non-empty buffer Producer: Consumer: produce(); wait(delay); wait (s); wait(s); append(); take(); signal(delay); signal(s); signal(s); consume();

  42. Monitors • Monitor is a software module • Chief characteristics • Local data variables are accessible only by the monitor • Process enters monitor by invoking one of its procedures • Only one process may be executing in the monitor at a time

  43. Monitors • synchronization - condition variables contained within the monitor and accessible only from within the monitor. • cwait(c) • csignal(c) • The advantage that monitors have over semaphores is that all of the synchronization functions are confined to the monitor.

  44. Monitors • cwait(c): Suspend execution of the calling process on condition c. The monitor is now available for use by another process. • csignal(c): Resume execution of some process suspended after a cwait on the same condition. If there are several such processes, choose one of them; if there is no such process, do nothing.

  45. Message Passing • Enforce mutual exclusion • Exchange information send (destination, message) receive (source, message)

  46. Synchronization • Sender and receiver may or may not be blocking (waiting for message) • Blocking send, blocking receive • Both sender and receiver are blocked until message is delivered • Called a rendezvous

  47. Synchronization • Nonblocking send, blocking receive • Sender continues processing such as sending messages as quickly as possible • Receiver is blocked until the requested message arrives • Nonblocking send, nonblocking receive • Neither party is required to wait

  48. Addressing • Direct addressing • send primitive includes a specific identifier of the destination process • receive primitive could know ahead of time which process a message is expected • receive primitive could use source parameter to return a value when the receive operation has been performed

  49. Addressing • Indirect addressing • messages are sent to a shared data structure consisting of queues • queues are called mailboxes • one process sends a message to the mailbox and the other process picks up the message from the mailbox

More Related