1 / 20

Process Synchronization

Process Synchronization. Notice: The slides for this lecture have been largely based on those accompanying the textbook Operating Systems Concepts with Java , by Silberschatz, Galvin, and Gagne (2003). Many, if not all, the illustrations contained in this presentation come from this source.

ahaddad
Download Presentation

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. Process Synchronization Notice: The slides for this lecture have been largely based on those accompanying the textbook Operating Systems Concepts with Java, by Silberschatz, Galvin, and Gagne (2003). Many, if not all, the illustrations contained in this presentation come from this source. CSCI 315 Operating Systems Design

  2. Deadlock and Starvation • Deadlock– two or more processes are waiting indefinitely for an event that can be caused by only one of the waiting processes. • Let S and Q be two semaphores initialized to 1 P0P1 acquire(S); acquire(Q); acquire(Q); acquire(S); . . . . . . release(S); release(Q); release(Q); release(S); • Starvation – indefinite blocking. A process may never be removed from the semaphore queue in which it is suspended. CSCI 315 Operating Systems Design

  3. The Dining-Philosophers Problem thinking hungry eating State diagram for a philosopher CSCI 315 Operating Systems Design

  4. The Dining-Philosophers Problem Question: How many philosophers can eat at once? How can we generalize this answer for n philosophers and m chopsticks? Question: What happens if the programmer initializes the semaphores incorrectly? (Say, two semaphores start out a zero instead of one.) Question: How can we formulate a solution to the problem so that there is no deadlock or starvation? CSCI 315 Operating Systems Design

  5. The Dining-Philosophers Problem thinking Shared data: semaphore chopstick[5]; (Initially all values are 1) hungry eating State diagram for a philosopher CSCI 315 Operating Systems Design

  6. Dining-Philosophers Solution? Philosopher i do { wait(chopstick[i]) wait(chopstick[(i+1) % 5]) … eat … signal(chopstick[i]); signal(chopstick[(i+1) % 5]); … think … } while (1); CSCI 315 Operating Systems Design

  7. Critical Regions • High-level synchronization construct. • A shared variable v of type T, is declared as: v:sharedT • Variable v accessed only inside statement: regionvwhenBdoSwhere B is a boolean expression. • While statement S is being executed, no other process can access variable v. CSCI 315 Operating Systems Design

  8. Critical Regions • Regions referring to the same shared variable exclude each other in time. • When a process tries to execute the region statement, the Boolean expression B is evaluated. If B is true, statement S is executed. If it is false, the process is delayed until B becomes true and no other process is in the region associated with v. CSCI 315 Operating Systems Design

  9. Implementationregion v when B do S • Associate with the shared variable x, the following variables: semaphore mutex, first-delay, second-delay; int first-count, second-count; (mutex is initialized to 1; first_delay and second_delay are initialized to 0; first_count and second_count are initialized to 0). • Mutually exclusive access to the critical section is provided by mutex. • If a process cannot enter the critical section because the Boolean expression B is false, it initially waits on the first-delaysemaphore; moved to the second-delaysemaphore before it is allowed to reevaluate B. CSCI 315 Operating Systems Design

  10. Implementation • Keep track of the number of processes waiting on first-delay and second-delay, with first-count and second-countrespectively. • The algorithm assumes FIFO ordering in the queuing of processes for a semaphore. • For an arbitrary queuing discipline, a more complicated implementation is required. CSCI 315 Operating Systems Design

  11. region v when B do S if (first_count > 0) signal(first_delay); else if (second_count > 0) signal(second_delay); else signal(mutex); wait(mutex); while (!B) { first_count++; if (second_count > 0) signal(second_delay); else signal(mutex); wait(first_delay); first_count--; second_count++; if (first_count > 0) signal(first_delay); else signal(second_delay); wait(second_delay); second_count--; } S; If a process cannot enter the critical section because B is false, it initially waits on first_delay. A process waiting on first_delay is eventually moved to second_delay before it is allowed to reevaluate its condition B. When a process leaves the critical section, it may have changed the value of some boolean condition B that prevented another process from entering the critical section. CSCI 315 Operating Systems Design

  12. Monitor Definition: High-level synchronization construct that allows the safe sharing of an abstract data type among concurrent processes. monitor monitor-name { shared variables procedure bodyP1(…) { . . . } procedure bodyP2 (…) { . . . } procedure bodyPn(…) { . . . } { initialization code } } A procedure within a monitor can access only local variables defined within the monitor. There cannot be concurrent access to procedures within the monitor (only one thread can be active inthe monitor at any given time). Condition variables:queues are associated with variables. Primitives for synchronization are wait and signal. CSCI 315 Operating Systems Design

  13. Schematic View of a Monitor CSCI 315 Operating Systems Design

  14. Monitor • To allow a process to wait within the monitor, a condition variable must be declared, as condition x, y; • Condition variable can only be used with the operations wait and signal. • The operation x.wait();means that the process invoking this operation is suspended until another process invokes x.signal(); • The x.signal operation resumes exactly one suspended process. If no process is suspended, then the signal operation has no effect. CSCI 315 Operating Systems Design

  15. Monitor and Condition Variables CSCI 315 Operating Systems Design

  16. Dining Philosophers with Monitor monitor dp { enum {thinking, hungry, eating} state[5]; condition self[5]; void pickup(int i); void putdown(int i); void test(int i); void init() { for (int i = 0; i < 5; i++) state[i] = thinking; } } CSCI 315 Operating Systems Design

  17. Dining Philosophers void pickup(int i) { state[i] = hungry; test[i]; if (state[i] != eating) self[i].wait(); } void putdown(int i) { state[i] = thinking; /* test left and right neighbors */ test((i+4) % 5); test((i+1) % 5); } void test(int i) { if ( (state[(I + 4) % 5] != eating) && (state[i] == hungry) && (state[(i + 1) % 5] != eating)) { state[i] = eating; self[i].signal(); } } CSCI 315 Operating Systems Design

  18. Monitor via Semaphores • Variables semaphore mutex; // (initially = 1) semaphore next; // (initially = 0) int next-count = 0; • Each external procedure F will be replaced by wait(mutex); … body of F; … if (next-count > 0) signal(next) else signal(mutex); • Mutual exclusion within a monitor is ensured. CSCI 315 Operating Systems Design

  19. Monitor via Semaphores • For each condition variable x, we have: semaphore x-sem; // (initially = 0) int x-count = 0; • The operation x.wait can be implemented as: x-count++; if (next-count > 0) signal(next); else signal(mutex); wait(x-sem); x-count--; CSCI 315 Operating Systems Design

  20. Monitor via Semaphores • The operation x.signal can be implemented as: if (x-count > 0) { next-count++; signal(x-sem); wait(next); next-count--; } CSCI 315 Operating Systems Design

More Related