Scribd
Upload
22 views

OS PPT 3-4

The document discusses synchronization tools used in operating systems including Peterson's solution, mutex locks, and semaphores. It describes the producer-consumer problem where a producer process produces items that are consumed by a consumer process. To synchronize access to shared memory and prevent race conditions, synchronization techniques like executing counter updates atomically are needed. The critical section problem where processes need exclusive access to a shared resource is also covered.

Uploaded by

drkhamuruddeen
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
22 views

OS PPT 3-4

The document discusses synchronization tools used in operating systems including Peterson's solution, mutex locks, and semaphores. It describes the producer-consumer problem where a producer process produces items that are consumed by a consumer process. To synchronize access to shared memory and prevent race conditions, synchronization techniques like executing counter updates atomically are needed. The critical section problem where processes need exclusive access to a shared resource is also covered.

Uploaded by

drkhamuruddeen
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 18

OPERATING SYSTEMS

UNIT III
.
Synchronization Tools
• The Critical-Section Problem
• Peterson’s Solution
• Synchronization Hardware
• Mutex Locks
• Semaphores
• Alternative Approaches
Synchronization
• Concurrent access to shared data may result in data
inconsistency
• Maintaining data consistency requires mechanisms to
ensure the orderly execution of cooperating processes
• The synchronization mechanism is usually provided
by both hardware and the operating system
• Illustration of the problem – The producer-Consumer
problem
• Basic assumption – load and store instructions are
atomic.
Producer-Consumer Problem in Cooperative process

• A producer process produces information that


is consumed by a consumer process.
• Example:
– A compiler may produce assembly code that is
consumed by an assembler.
– The assembler may produce object modules that
are consumed by the loader.
Producer-Consumer Problem in Cooperative process

• One solution to the producer–consumer problem uses shared


memory.
• To allow producer and consumer processes to run
concurrently, we must have available a buffer of items that can
be filled by the producer and emptied by the consumer.
• This buffer will reside in a region of memory that is shared by
the producer and consumer processes.
• A producer can produce one item while the consumer is
consuming another item.
• The producer and consumer must be synchronized, so that the
consumer does not try to consume an item that has not yet
been produced.
Producer-Consumer Problem in Cooperative process

• Two types of buffers can be used. Unbounded


Buffer and Bounded Buffer
– Unbounded Buffer: The size of the buffer is not
limited. The consumer may have to wait for new
items, but the producer can always produce new
items.
– Bounded Buffer: The buffer size is limited. The
consumer must wait if the buffer is empty and the
producer must wait if the buffer is full.
Producer-Consumer Problem
• Suppose that we wanted to provide a solution that fills
all the buffers where we allow the producer and
consumer processes to increment and decrement the
same variable.
• We can do so by adding another integer variable --
counter that keeps track of the number of full buffers.
Initially, counter is set to 0.
• The variable counter It is incremented by the producer
after it produces a new buffer and is decremented by
the consumer after it consumes a buffer.
• Code is shown in next slides
Producer-Consumer Problem in
Cooperative process
• Code for Producer and Consumer Process in Bounded Buffer
IPC
Following variables reside in shared memory region by the
producer and consumer processes:
#define BUFFER_SIZE 10
typedef struct {
............
}item;
item buffer[BUFFER_SIZE];
int in = 0;
int out = 0;
Producer Process
while (true) {
/* produce an item in next produced
*/

while (counter == BUFFER_SIZE) ;


/* do nothing */
buffer[in] = next_produced;
in = (in + 1) % BUFFER_SIZE;
counter = counter +1;
}
Consumer Process
while (true) {
while (counter == 0)
; /* do nothing */
next_consumed = buffer[out];
out = (out + 1) % BUFFER_SIZE;
counter = counter - 1;

/* consume the item in next


consumed */
}
Race Condition
• counter = counter + 1 could be implemented as
register1 = counter
register1 = register1 + 1
counter = register1
• counter = counter -1 could be implemented as
register2 = counter
register2 = register2 - 1
counter = register2
• Consider this execution interleaving with “count = 5” initially:
S0: producer execute register1 = counter {register1 = 5}
S1: producer execute register1 = register1 + 1 {register1 = 6}
S2: consumer execute register2 = counter {register2 = 5}
S3: consumer execute register2 = register2 – 1 {register2 = 4}
S4: producer execute counter = register1 {counter = 6 }
S5: consumer execute counter = register2 {counter = 4}
Race Condition (Cont.)
• How do we solve the race condition?
• We need to make sure that:
– The execution of
counter = counter + 1
is executed as an “atomic” action. That is, while it is being executed,
no other instruction can be executed concurrently.
– Similarly for
counter = counter - 1
• The ability to execute an instruction, or a number of instructions,
atomically is crucial for being able to solve many of the synchronization
problems.
Critical Section Problem
• Consider system of n processes {P0, P1, … Pn-1}
• Each process has critical section segment of code
– Process may be changing common variables, updating table, writing file, etc
– When one process in critical section, no other may be in its critical section
• Critical section problem is to design protocol to solve this
• Each process must ask permission to enter critical section in entry section code;
it than executes in the critical section; once it finishes executing in the critical
section it enters the exit section code. The process then enters the remainder
section code.
General structure of Process Entering the
Critical Section
• General structure of process Pi
Algorithm for Process Pi
• Entry section to critical section is to “disable interrupts.
• Execute in the critical section
• Exit section is to “enable interrupts”.
• Implementation issues:
– Uniprocessor systems
• Currently running code would execute without preemption
– Multiprocessor systems.
• Generally too inefficient on multiprocessor systems
• Operating systems using this not broadly scalable
• Is this an acceptable solution?
– This is impractical if the critical section code is taking a long time to execute.
Algorithm for Process Pi
• Keep a variable “turn” to indicate which process is next Execute in the
critical section

do {
while (turn == j);

critical section
turn = j;

remainder section
} while (true);

■ Algorithm is correct. Only one process at a time in the critical section. But:
■ Results in “busy waiting”.
■ If Pi wants to enter then critical section and turn = j and Pj does not want to
enter the critical section ….
Solution to Critical-Section Problem
1. Mutual Exclusion - If process Pi is executing in its critical section, then no other
processes can be executing in their critical sections
2. Progress - If no process is executing in its critical section and there exist some
processes that wish to enter their critical section, then the selection of the
processes that will enter the critical section next cannot be postponed indefinitely
3. Bounded Waiting - A bound must exist on the number of times that other
processes are allowed to enter their critical sections after a process has made a
request to enter its critical section and before that request is granted
⚫ Assume that each process executes at a nonzero speed
⚫ No assumption concerning relative speed of the n processes

You might also like