process synchronization. whenever processes share things, there is a chance for screwing up things ...

21
Process Synchronization

Upload: erin-atkinson

Post on 05-Jan-2016

215 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Process Synchronization.  Whenever processes share things, there is a chance for screwing up things  For example ◦ Two processes sharing one printer

Process Synchronization

Page 2: Process Synchronization.  Whenever processes share things, there is a chance for screwing up things  For example ◦ Two processes sharing one printer

Whenever processes share things, there is a chance for screwing up things

For example◦ Two processes sharing one printer◦ Two processes updating one database record◦ Two processes sharing a single counter

Page 3: Process Synchronization.  Whenever processes share things, there is a chance for screwing up things  For example ◦ Two processes sharing one printer

Two processes – one a producer of something, and one a consumer of something

The producer produces something and places the something into a buffer

The consumer consumes the something, taking the something out of the buffer

Once again two processes are sharing something – the buffer

Page 4: Process Synchronization.  Whenever processes share things, there is a chance for screwing up things  For example ◦ Two processes sharing one printer

repeat repeat : while counter = 0 do no-op;produce an item in nextp (buffer is empty) : nextc := buffer[out];while counter = n do no-op; out := out + 1 mod n; (buffer is full) counter := counter – 1;buffer[in] := nextp; :in := in + 1 mod n; consume the item in nextccounter := counter + 1; :

until false; until false;

PRODUCER CONSUMER

Page 5: Process Synchronization.  Whenever processes share things, there is a chance for screwing up things  For example ◦ Two processes sharing one printer

Note that both the producer and the consumer reference variable counter

In the producer: counter := counter + 1 which in machine language is:

◦ register1 := counter;◦ register1 := register1 + 1;◦ counter := register1;

Page 6: Process Synchronization.  Whenever processes share things, there is a chance for screwing up things  For example ◦ Two processes sharing one printer

In the consumer: counter := counter - 1 Which in machine language is:

◦ register2 := counter◦ register2 := register2 - 1◦ counter := register2

counter could be 4, 5 or 6 depending upon where the code is interrupted

For example:

Page 7: Process Synchronization.  Whenever processes share things, there is a chance for screwing up things  For example ◦ Two processes sharing one printer

counter is at 5 and producer starts: register1 := counter; register1 = 5 register1 := register1 + 1; register1 = 6 the producer is swapped out and the consumer

starts anew register2 := counter; register2 = 5 register2 := register2 - 1; register2 = 4 the consumer is swapped out and the producer

returns counter := register1; counter = 6 the producer is done, and the consumer returns counter := register2; counter = 4 counter should be 5!

Page 8: Process Synchronization.  Whenever processes share things, there is a chance for screwing up things  For example ◦ Two processes sharing one printer

Thus, the accessing of counter is a critical section

What happens above is called a race condition

Must ensure than ONLY one process at a time references counter

We need process synchronization

Page 9: Process Synchronization.  Whenever processes share things, there is a chance for screwing up things  For example ◦ Two processes sharing one printer

To solve critical section problem, three things are needed◦ Mutual exclusion – only one at a time◦ Progress – process moves through event◦ Bounded waiting – everyone has to get a turn

Page 10: Process Synchronization.  Whenever processes share things, there is a chance for screwing up things  For example ◦ Two processes sharing one printer

A simple, clean way to support process synchronization

Supported by many OSs and even some processors

A semaphore is nothing more than an integer.

But, this integer can only be accessed (except for initialization) through two atomic operations:

Page 11: Process Synchronization.  Whenever processes share things, there is a chance for screwing up things  For example ◦ Two processes sharing one printer

wait(s): if s = 0 then go to sleep;s := s – 1;

signal(s): s := s + 1;wakeup sleeping process;

Page 12: Process Synchronization.  Whenever processes share things, there is a chance for screwing up things  For example ◦ Two processes sharing one printer

To use semaphores, create a structure that looks like the following:

repeat:wait(semaphore)

:(critical section)

:signal(semaphore):

until false;

Page 13: Process Synchronization.  Whenever processes share things, there is a chance for screwing up things  For example ◦ Two processes sharing one printer

Database update in which you want to lock out all but one concurrent user

procedure UpdateDatabase;var s: semaphore (:=1);begin

:(prompt user for data)

:wait(s);Update(record);signal(s);

:end;

Page 14: Process Synchronization.  Whenever processes share things, there is a chance for screwing up things  For example ◦ Two processes sharing one printer

CD-ROM reader which allows 5 concurrent users

procedure ReadCD;var t: semaphore (:=5);begin

:(prompt user for data)

:wait(t);ReadCD(buffer);signal(t);

:end;

Page 15: Process Synchronization.  Whenever processes share things, there is a chance for screwing up things  For example ◦ Two processes sharing one printer

Let’s re-visit the producer/consumer problem and solve the problem using semaphores (on the whiteboard)

Page 16: Process Synchronization.  Whenever processes share things, there is a chance for screwing up things  For example ◦ Two processes sharing one printer

var s: semaphore (:=1); n: semaphore (:=0); e: semaphore (:=sizeofbuffer);

procedure producer;begin

repeatproduce item for buffer;wait (e);wait(s); append to buffer;signal(s);signal(n);

forever;end;

procedure consumer;begin

repeatwait(n);wait(s); take from buffer;signal(s);signal(e);consume item

forever;end;

Page 17: Process Synchronization.  Whenever processes share things, there is a chance for screwing up things  For example ◦ Two processes sharing one printer

When two or more processes have conflicting needs for resources, we have deadlock

Example: P1 holds the disk and wants the tape; P2 holds the tape and wants the disk

Example: P1 has 80K or memory and wants 60K more; P2 has 70K of memory and wants 80K more; there is only 150K total of memory

Page 18: Process Synchronization.  Whenever processes share things, there is a chance for screwing up things  For example ◦ Two processes sharing one printer

Three conditions must first exist for deadlock to occur:1. Mutual exclusion2. Hold and wait3. No preemption

Then the following must happen:4. Circular wait

How do you avoid deadlock?

Page 19: Process Synchronization.  Whenever processes share things, there is a chance for screwing up things  For example ◦ Two processes sharing one printer

Indirect methods – stop one of the conditions 1-3 from happening (not desirable)

Direct methods – stop occurrence of condition 4 from happening

For example: Order all resources from 0 to N. If you have resource m, you can only ask for a resource > m, where Disk=5; Tape=7; Printer=12

Page 20: Process Synchronization.  Whenever processes share things, there is a chance for screwing up things  For example ◦ Two processes sharing one printer

Really is prevention, but not as restrictive Avoidance allows the 3 conditions but

makes dynamic decisions whether a current resource allocation request will lead to deadlock, such as Bankers’ Algorithm

Page 21: Process Synchronization.  Whenever processes share things, there is a chance for screwing up things  For example ◦ Two processes sharing one printer

Use an algorithm that can detect cycles in directed graphs

Costly, as OS must maintain graphs and check for cycles