Operating System - Process Syncronization Part 3 - Notes, Study notes of Operating Systems

Download Operating System - Process Syncronization Part 3 - Notes and more Study notes Operating Systems in PDF only on Docsity!

PROCESS SYNCHRONIZATION

How to implement Mutual

Exclusion

• (^) Disabling interrupts
• (^) Lock Variables
• (^) Turn Variables
• (^) Peterson solution
• (^) TSL Instruction
• (^) Sleep and Wakeup

Solution to IPC

• (^) Semaphore
• (^) Mutex Variable
• (^) Monitor

Common Drawbacks of previous

methods

• (^) Busy waiting: when a process wants to enter its critical region, it checks to see if the entry is allowed.
• (^) If it is not, the process just sits in a tight loop waiting until it is.
• (^) Wastage of CPU time
• (^) Unexpected error.: Priority inversion problem.

Priority inversion problem

• (^) At a certain moment, with L in its critical region, H becomes ready to run (e.g., an I/O operation completes).
• (^) H now begins busy waiting, but since L is never scheduled while H is running, L never gets the chance to leave its critical region, so H loops forever.

• This is known as Priority inversion problem.

Solution

• (^) Sleep and wakeup.
• (^) Sleep is a system call that causes the caller to block, that is, be suspended until another process wakes it up.
• (^) The wakeup call has one parameter, the process to be awakened.
• (^) Alternatively, both sleep and wakeup each have one parameter, a memory address used to match up sleep s with wakeup s.

The Producer-Consumer

Problem

• (^) Trouble arises when the producer wants to put a new item in the buffer, but it is already full.
• (^) The solution is for the producer to go to sleep, to be awakened when the consumer has removed one or more items.
• (^) Similarly, if the consumer wants to remove an item from the buffer and sees that the buffer is empty, it goes to sleep until the producer puts something in the buffer and wakes it up.

The Producer-Consumer

Problem

• (^) This approach sounds simple enough, but it leads to the same kinds of race conditions.
• (^) To keep track of the number of items in the buffer, we will need a variable, count.
• (^) If the maximum number of items the buffer can hold is N , the producer's code will first test to see if count is N.
• (^) If it is, the producer will go to sleep; if it is not, the producer will add an item and increment count.

• (^) Sleep and Wake up system calls are avilable with the system.

Race condition may be there.

The following situation could possibly occur.

• (^) The buffer is empty and the consumer has just read count to see if it is 0.
• (^) At that instant, the scheduler decides to stop running the consumer temporarily and start running the producer.

Race condition.

• (^) The producer enters an item in the buffer, increments count , and notices that it is now 1.
• (^) Reasoning that count was just 0, and thus the consumer must be sleeping, the producer calls wakeup to wake the consumer up.
• (^) Unfortunately, the consumer is not yet logically asleep, so the wakeup signal is lost.

Race condition.

• (^) The essence of the problem here is that a wakeup sent to a process that is not (yet) sleeping is lost.
• (^) If it were not lost, everything would work.
• (^) How to solve the racing condition.

A better managed Sleep and wait

• (^) By using a wake up bit.
• (^) By using a Semaphore.