![Page 1: Process Synchronization. Whenever processes share things, there is a chance for screwing up things For example ◦ Two processes sharing one printer](https://reader036.vdocument.in/reader036/viewer/2022070403/56649f2b5503460f94c46326/html5/thumbnails/1.jpg)
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](https://reader036.vdocument.in/reader036/viewer/2022070403/56649f2b5503460f94c46326/html5/thumbnails/2.jpg)
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](https://reader036.vdocument.in/reader036/viewer/2022070403/56649f2b5503460f94c46326/html5/thumbnails/3.jpg)
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](https://reader036.vdocument.in/reader036/viewer/2022070403/56649f2b5503460f94c46326/html5/thumbnails/4.jpg)
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](https://reader036.vdocument.in/reader036/viewer/2022070403/56649f2b5503460f94c46326/html5/thumbnails/5.jpg)
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](https://reader036.vdocument.in/reader036/viewer/2022070403/56649f2b5503460f94c46326/html5/thumbnails/6.jpg)
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](https://reader036.vdocument.in/reader036/viewer/2022070403/56649f2b5503460f94c46326/html5/thumbnails/7.jpg)
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](https://reader036.vdocument.in/reader036/viewer/2022070403/56649f2b5503460f94c46326/html5/thumbnails/8.jpg)
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](https://reader036.vdocument.in/reader036/viewer/2022070403/56649f2b5503460f94c46326/html5/thumbnails/9.jpg)
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](https://reader036.vdocument.in/reader036/viewer/2022070403/56649f2b5503460f94c46326/html5/thumbnails/10.jpg)
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](https://reader036.vdocument.in/reader036/viewer/2022070403/56649f2b5503460f94c46326/html5/thumbnails/11.jpg)
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](https://reader036.vdocument.in/reader036/viewer/2022070403/56649f2b5503460f94c46326/html5/thumbnails/12.jpg)
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](https://reader036.vdocument.in/reader036/viewer/2022070403/56649f2b5503460f94c46326/html5/thumbnails/13.jpg)
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](https://reader036.vdocument.in/reader036/viewer/2022070403/56649f2b5503460f94c46326/html5/thumbnails/14.jpg)
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](https://reader036.vdocument.in/reader036/viewer/2022070403/56649f2b5503460f94c46326/html5/thumbnails/15.jpg)
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](https://reader036.vdocument.in/reader036/viewer/2022070403/56649f2b5503460f94c46326/html5/thumbnails/16.jpg)
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](https://reader036.vdocument.in/reader036/viewer/2022070403/56649f2b5503460f94c46326/html5/thumbnails/17.jpg)
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](https://reader036.vdocument.in/reader036/viewer/2022070403/56649f2b5503460f94c46326/html5/thumbnails/18.jpg)
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](https://reader036.vdocument.in/reader036/viewer/2022070403/56649f2b5503460f94c46326/html5/thumbnails/19.jpg)
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](https://reader036.vdocument.in/reader036/viewer/2022070403/56649f2b5503460f94c46326/html5/thumbnails/20.jpg)
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](https://reader036.vdocument.in/reader036/viewer/2022070403/56649f2b5503460f94c46326/html5/thumbnails/21.jpg)
Use an algorithm that can detect cycles in directed graphs
Costly, as OS must maintain graphs and check for cycles