Presentation is loading. Please wait.

Presentation is loading. Please wait.

02/25/2004CSCI 315 Operating Systems Design1 Process Synchronization Notice: The slides for this lecture have been largely based on those accompanying.

Similar presentations


Presentation on theme: "02/25/2004CSCI 315 Operating Systems Design1 Process Synchronization Notice: The slides for this lecture have been largely based on those accompanying."— Presentation transcript:

1 02/25/2004CSCI 315 Operating Systems Design1 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.

2 02/25/2004CSCI 315 Operating Systems Design2 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 P 0 P 1 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.

3 02/25/2004CSCI 315 Operating Systems Design3 The Dining-Philosophers Problem thinking hungry eating State diagram for a philosopher

4 02/25/2004CSCI 315 Operating Systems Design4 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?

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

6 02/25/2004CSCI 315 Operating Systems Design6 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);

7 02/25/2004CSCI 315 Operating Systems Design7 Critical Regions High-level synchronization construct. A shared variable v of type T, is declared as: v: shared T Variable v accessed only inside statement: region v when B do S where B is a boolean expression. While statement S is being executed, no other process can access variable v.

8 02/25/2004CSCI 315 Operating Systems Design8 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.

9 02/25/2004CSCI 315 Operating Systems Design9 Implementation region 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-delay semaphore; moved to the second-delay semaphore before it is allowed to reevaluate B.

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

11 02/25/2004CSCI 315 Operating Systems Design11 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 (first_count > 0) signal(first_delay); else if (second_count > 0) signal(second_delay); else signal(mutex); region v when B do 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.

12 02/25/2004CSCI 315 Operating Systems Design12 Monitor Definition: High-level synchronization construct that allows the safe sharing of an abstract data type among concurrent processes. 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 in the monitor at any given time). Condition variables: queues are associated with variables. Primitives for synchronization are wait and signal. monitor monitor-name { shared variables procedure body P1 (…) {... } procedure body P2 (…) {... } procedure body Pn (…) {... } { initialization code }

13 02/25/2004CSCI 315 Operating Systems Design13 Schematic View of a Monitor

14 02/25/2004CSCI 315 Operating Systems Design14 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.

15 02/25/2004CSCI 315 Operating Systems Design15 Monitor and Condition Variables

16 02/25/2004CSCI 315 Operating Systems Design16 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; }

17 02/25/2004CSCI 315 Operating Systems Design17 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(); }

18 02/25/2004CSCI 315 Operating Systems Design18 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.

19 02/25/2004CSCI 315 Operating Systems Design19 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--;

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


Download ppt "02/25/2004CSCI 315 Operating Systems Design1 Process Synchronization Notice: The slides for this lecture have been largely based on those accompanying."

Similar presentations


Ads by Google