1 / 63

Chapter 5: Process Synchronization

Chapter 5: Process Synchronization. Announcement. Finish reading Chapter 5 by next Wednesday. First Midterm: Friday Sep 29. Covering Chapters 1, 3, 4, & 5. Objectives. To present the concept of process synchronization

Download Presentation

Chapter 5: Process 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 5: Process Synchronization

  2. Announcement • Finish reading Chapter 5 by next Wednesday. • First Midterm: Friday Sep 29. • Covering Chapters 1, 3, 4, & 5

  3. Objectives • To present the concept of process synchronization • To introduce the critical-section problem, whose solutions can be used to ensure the consistency of shared data • To present solutions of the critical-section problem • To examine several classical process-synchronization problems • To explore several tools that are used to solve process synchronization problems

  4. Background • Processes can execute concurrently on a uniprocessor • May be interrupted at any time, partially completing execution • Processes can execute in parallel on a multicore computer • Concurrent and parallel access to shared data may result in data inconsistency • Maintaining data consistency requires mechanisms to ensure the orderly execution of cooperating processes

  5. Illustrative Example • Suppose that we are developing a solution to the consumer-producer problem, where we use an integer counterto keep track of the number of full buffers. Initially, counteris set to 0. It is incremented by the producer after it produces a new buffer and is decremented by the consumer after it consumes a buffer.

  6. Producer while (true) { /* produce an item in next produced */ while (counter == BUFFER_SIZE) ; /* do nothing */ buffer[in] = next_produced; in = (in + 1) % BUFFER_SIZE; counter++; }

  7. Consumer while (true) { while (counter == 0) ; /* do nothing */ next_consumed = buffer[out]; out = (out + 1) % BUFFER_SIZE; counter--; /* consume the item in next consumed */ }

  8. Race Condition: Example • counter++ could be implemented as register1 = counter register1 = register1 + 1 counter = register1 • counter--could be implemented asregister2 = counter register2 = register2 - 1 counter = register2 • If “counter = 5” initially, what is the desired final counter value • Consider this execution interleaving with “counter = 5” initially: S0: producer execute register1 = counter{register1 = 5}S1: producer execute register1 = register1 + 1 {register1 = 6} S2: consumer execute register2 = counter{register2 = 5} S3: consumer execute register2 = register2 – 1 {register2 = 4} S4: producer execute counter = register1 {counter = 6 } S5: consumer execute counter = register2 {counter = 4}

  9. Race Condition: Definition A situation where several processes access and manipulate the same data concurrently and the outcome of the execution depends on the particular order in which the access takes place.

  10. Critical Section Problem • Consider system of nprocesses {p0, p1, … pn-1} • Each process has critical section segment of code • Process may be changing common variables, updating table, writing file, etc. • When one process in critical section, no other may be in its critical section • Critical section problem is to design protocol to solve this • Each process must ask permission to enter critical section in entry section, will follow critical section with exit section, then remainder section

  11. Critical Section • General structure of process Pi

  12. Solution to Critical-Section Problem 1. Mutual Exclusion - If process Piis executing in its critical section, then no other processes can be executing in their critical sections 2. Progress– When no process is in a critical section, any process that requests entry to its critical section must be permitted to enter without delay. 3. 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 thenprocesses

  13. Mutual Exclusion Approaches • Software approach • Self-read Chap 5.3 (Peterson’s Solution) • Hardware support, using special-purpose machine instructions • Support within OS or a programming language • Semaphore, Message Passing, Monitors

  14. Mutual Exclusion: Hardware Support • Interrupt Disabling • A process runs until it invokes an operating system service or until it is interrupted • Disabling interrupts guarantees mutual exclusion • Disadvantages: • Processor is limited in its ability to interleave programs • Will not work in multiprocessor architecture

  15. Mutual Exclusion: Hardware Support • Compare&Swap Instruction int compare_and_swap (int *word, int testval, int newval) { int oldval; oldval = *word; if (oldval == testval) *word = newval; return oldval; }

  16. Mutual Exclusion

  17. Mutual Exclusion: Hardware Support • Exchange instruction void exchange (int *register, int *memory) { int temp; temp = *memory; *memory = *register; *register = temp; }

  18. Mutual Exclusion

  19. Mutual Exclusion Machine-Instruction • Advantages • Applicable to any number of processes on a single processor • Processes on multiple processors? • as long as processors share main memory • It is simple and therefore easy to verify • It can be used to support multiple critical sections; each critical section can be defined by its own variable (e.g. bolt1, bolt2, etc.)

  20. Mutual Exclusion Machine-Instruction • Disadvantages • Busy-waiting consumes processor time • Starvation? • Starvation is possible when a process leaves a critical section and more than one process is waiting, lower priority processes may suffer starvation.

  21. Semaphores • Special variable called a semaphore is used for signaling • If a process is waiting for a signal, it is blocked until that signal is sent • 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

  22. Semaphore Primitives

  23. Example of Semaphore Mechanism

  24. Example of Semaphore Mechanism

  25. Mutual Exclusion Using Semaphores

  26. Mutual Exclusion Using Semaphores

  27. Processes Using Semaphore

  28. Semaphore Implementation: Atomic Primitives

  29. Mutual Exclusion Machine-Instruction vs. Semaphore

  30. Mutual Exclusion Machine-Instruction vs. Semaphore

  31. Producer/Consumer Problem • One or more producers are generating data and placing these in a buffer • One or more consumers are taking items out of the buffer one at time • Only one producer or consumer may access the buffer at any one time • Producer can’t add data into full buffer and consumer can’t remove data from empty buffer

  32. Circular Buffer

  33. Producer & Consumer with Circular Buffer • consumer: • while (true) { while (counter==0); /* do nothing */ v=buffer[out]; out=(out + 1)%BUFFER_SIZE; counter--; /* consume item v */ • } • producer: while (true) { /* produce item v */ while(counter==BUFFER_SIZE); /* do nothing */ buffer[in]=v; in=(in + 1)%BUFFER_SIZE; counter++; } • How to ensure “only one producer or consumer may access the buffer at any one time”? • How to ensure “producer can’t add data into full buffer and consumer can’t remove data from empty buffer”?

  34. Synchronization using Semaphore?

  35. Semaphores

  36. Binary Semaphore Primitives

  37. Mutual Exclusion Approaches • Software approach • Self-read Chap 5.3 (Peterson’s Solution) • Hardware support, using special-purpose machine instructions • Support within OS or a programming language • Semaphore, Message Passing, Monitors

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

  39. Synchronization • The receiver cannot receive a message until it has been sent by another process • Blocking or nonblocking primitives • Blocking primitives: sender and receiver will be blocked (waiting for message) • Nonblocking primitives: sender and receiver will not be blocked (waiting for message)

  40. Addressing • Direct addressing • Send primitive includes a specific identifier of the destination process • Receive primitive may/may not know ahead of time from which process a message is expected • Receive primitive could use source parameter to return a value when the receive operation has been performed

  41. 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

  42. Indirect Process Communication

  43. Mutual Exclusion Using Messages (1) • Assume • blocking receive primitive & • nonblocking send primitive • indirect addressing

  44. Mutual Exclusion Using Messages (2)

  45. Readers/Writers Problem • Any number of readers may simultaneously read the file • Only one writer at a time may write to the file • If a writer is writing to the file, no reader may read it • How is this problem different from mutual exclusion problem? • Cast it to a mutual exclusion problem?

  46. Any Problem with This Solution?

  47. Readers have Priority

  48. Writers Have Priority • The following semaphores and variables are added: • A semaphore rsem that inhibits all readers while there is at least one writer desiring access to the data area • A variable writecount that controls the setting of rsem • A semaphore y that controls the updating of writecount • A semaphore z that prevents a long queue of readers to build up on rsem

  49. Writers have Priority

More Related