process synchronization
Skip this Video
Download Presentation
Process Synchronization

Loading in 2 Seconds...

play fullscreen
1 / 29

Process Synchronization - PowerPoint PPT Presentation

  • Uploaded on

Process Synchronization. Definition. The term process is a generic term for both a process and a thread Processes that do not interact are independent processes Process synchronization is a generic term for the techniques used to delay and resume processes to implement process interactions.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' Process Synchronization' - donovan-dease

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
  • The term process is a generic term for both a process and a thread
  • Processes that do not interact are independent processes
  • Process synchronization is a generic term for the techniques used to delay and resume processes to implement process interactions
race condition
Race Condition
  • Uncoordinated accesses to shared data may affect consistency of data
  • Consider processes Piand Pjthat update the value of dsthrough operations aiand aj, respectively:

Operation ai: ds:= ds+ 10; Let fi(ds) represent its result

Operation aj: ds:= ds+ 5; Let fj(ds) represent its result

    • What situation could arise if they execute concurrently?
why synchronization
Why Synchronization
  • Concurrent access to shared data may result in data inconsistency.
  • Maintaining data consistency requires mechanisms to ensure the orderly execution of cooperating processes.
producer consumer problem
Producer Consumer Problem
  • solution must satisfy the following:
    • A producer must not overwrite a full buffer
    • A consumer must not consume an empty buffer
    • Producers and consumers must access buffers in a mutually exclusive manner
    • (Optional)Information must be consumed in the same order in which it is put into the buffers
producer consumer problem cont
Producer Consumer Problem(Cont..)
  • Shared data typeitem = … ;

varbufferarray [0..n-1] of item;

in, out: 0..n-1;

counter: 0..n;

in, out, counter := 0;

  • Producer process


{ …

produce an item in nextp

while (counter == n); // do no-op;

buffer [in] := nextp;

in := in + 1 modn;

counter := counter +1;


producer consumer problem cont1
Producer Consumer Problem (Cont..)
  • Consumer process



while (counter = =0 ); //dono-op;

nextc := buffer [out];

out := out + 1 modn;

counter := counter – 1;

consume the item in nextc


  • The statements:
    • counter := counter + 1;
    • counter := counter - 1;

must be executed atomically.

critical section problem
Critical Section Problem
  • n processes all competing to use some shared data
  • Each process has a code segment, called critical section, in which the shared data is accessed.
  • Problem – ensure that when one process is executing in its critical section, no other process is allowed to execute in its critical section.
  • Structure of process Pi
solution to critical section problem
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.
initial attempt
Initial Attempt
  • Only 2 processes, P0 and P1
  • General structure of process Pi(other process Pj)


entry section

critical section

exit section

reminder section


  • Processes may share some common variables to synchronize their actions.
algorithm 3 peterson s solution
Algorithm 3 (Peterson’s Solution)
  • Combined shared variables of algorithms 1 and 2.
  • Process Pi

Meets all three requirements; solves the critical-section problem for two processes.

  • Synchronization tool that does not require busy waiting.
  • Semaphore S – integer variable
  • can only be accessed via two indivisible (atomic) operations
    • wait (S) {

while S <= 0 ; // no-op



    • signal (S) {



semaphore implementation
Semaphore Implementation
  • Define a semaphore as a record

typesemaphore = record

value: integer

L: list ofprocess;


  • Assume two simple operations:
    • block suspends the process that invokes it.
    • wakeup(P) resumes the execution of a blocked process P.
implementation cont
  • Semaphore problem: Busy waiting. Process waiting to enter CS loop continuously wasting CPU Cycles called Spin lock.
  • Modification: Waiting process places itself in waiting queue associated with semaphore. block(), wakeup().
  • Implementation of wait:

wait(semaphore *S) {

S->value- -;

if (S->value < 0) {

add this process to S->list;




  • Implementation of signal:

signal(semaphore *S) {


if (S->value <= 0) {

remove a process P from S->list;




producer consumer problem1
Producer Consumer Problem
  • N buffers, each can hold one item
  • Semaphore mutex initialized to the value 1
  • Semaphore full initialized to the value 0
  • Semaphore empty initialized to the value N
producer consumer problem cont2
Producer Consumer Problem(Cont..)
  • The structure of the producer process

do {

// produce an item in nextp

wait (empty);

wait (mutex);

// add the item to the buffer

signal (mutex);

signal (full);

} while (TRUE);

producer consumer problem cont3
Producer Consumer Problem(Cont..)
  • The structure of the consumer process

do {

wait (full);

wait (mutex);

// remove an item from buffer to nextc

signal (mutex);

signal (empty);

// consume the item in nextc

} while (TRUE);

reader writer problem
Reader Writer Problem
  • A data set is shared among a number of concurrent processes
    • Readers – only read the data set; they do not perform any updates
    • Writers – can both read and write
  • Problem – allow multiple readers to read at the same time
    • Only one single writer can access the shared data at the same time
  • Several variations of how readers and writers are treated – all involve priorities
  • Shared Data
    • Data set
    • Semaphore mutex initialized to 1
    • Semaphore wrt initialized to 1
    • Integer readcount initialized to 0
reader writer problem1
Reader Writer Problem
  • The structure of a reader process

do {

wait (mutex) ;

readcount ++ ;

if (readcount == 1)

wait (wrt) ;

signal (mutex)

// reading is performed

wait (mutex) ;

readcount - - ;

if (readcount == 0)

signal (wrt) ;

signal (mutex) ;

} while (TRUE);

  • The structure of a writer process

do {

wait (wrt) ;

// writing is performed

signal (wrt) ;

} while (TRUE);

dining philosophers problem
Dining Philosophers Problem
  • Philosophers spend their lives thinking and eating
  • Don’t interact with their neighbors, occasionally try to pick up 2 chopsticks (one at a time) to eat from bowl
    • Need both to eat, then release both when done
  • In the case of 5 philosophers
    • Shared data
      • Bowl of rice (data set)
      • Semaphore chopstick [5] initialized to 1
dining philosophers problem cont
Dining Philosophers Problem(Cont..)
  • The structure of Philosopheri:

do {

wait ( chopstick[i] );

wait ( chopStick[ (i + 1) % 5] );

// eat

signal ( chopstick[i] );

signal (chopstick[ (i + 1) % 5] );

// think

} while (TRUE);

  • A monitor type resembles a class in a language like C++ or Java
    • Contains declarations of shared data
    • Only one process may be active within the monitor at a time.
    • Its procedures encode operations that manipulate shared data and implement process synchronization
      • A condition is a situation of interest in a monitor
      • A condition variable is associated with a condition
      • A process executing a wait operation on condition variable is blocked until some process performs a signal operation.
structure of monitor
Structure of Monitor

typemonitor-name = monitor

variable declarations

procedure entryP1 :(…);

begin … end;


begin … end;

procedure entryPn (…);



initialization code


condition variables
Condition Variables
  • To allow a process to wait within the monitor, a condition variable must be declared, as

varx, y: condition

  • 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


    • The x.signal operation resumes exactly one suspended process. If no process is suspended, then the signal operation has no effect