process synchronization
Download
Skip this Video
Download Presentation
Process Synchronization

Loading in 2 Seconds...

play fullscreen
1 / 44

Process Synchronization - PowerPoint PPT Presentation


  • 275 Views
  • Uploaded on

Process Synchronization. Module 5: Process Synchronization. Background The Critical-Section Problem Peterson’s Solution Synchronization Hardware Semaphores Classic Problems of Synchronization Monitors Synchronization Examples . Background.

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

PowerPoint Slideshow about ' Process Synchronization' - jaeger


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
module 5 process synchronization
Process SynchronizationModule 5: Process Synchronization
  • Background
  • The Critical-Section Problem
  • Peterson’s Solution
  • Synchronization Hardware
  • Semaphores
  • Classic Problems of Synchronization
  • Monitors
  • Synchronization Examples
background
Process SynchronizationBackground
  • Concurrent access to shared data may result in data inconsistency
  • Maintaining data consistency requires mechanisms to ensure the orderly execution of cooperating processes
  • Suppose that we wanted to provide a solution to the producer-consumer problem that fills all the buffers.
  • We can do so by having an integer count that keeps track of the number of full buffers. Initially, count is set to 0.
  • It is incremented by the producer after it produces a new buffer and is decremented by the consumer after it consumes a buffer.
producer
Process SynchronizationProducer

while (true)

/* produce an item and put in nextProduced

while (count == BUFFER_SIZE)

; // do nothing

buffer [in] = nextProduced;

in = (in + 1) % BUFFER_SIZE;

count++;

}

  • count++ could be implemented asregister1 = count register1 = register1 + 1 count = register1
consumer
Process SynchronizationConsumer

while (1)

{

while (count == 0)

; // do nothing

nextConsumed = buffer[out];

out = (out + 1) % BUFFER_SIZE;

count--;

/* consume the item in nextConsumed

}

  • count-- could be implemented as register2 = count register2 = register2 - 1 count = register2
race condition
Process SynchronizationRace Condition
  • Consider this execution interleaving with “count = 5” initially:

S0: producer execute register1 = count {register1 = 5}S1: producer execute register1 = register1 + 1 {register1 = 6} S2: consumer execute register2 = count {register2 = 5} S3: consumer execute register2 = register2 - 1 {register2 = 4} S4: producer execute count = register1 {count = 6 } S5: consumer execute count = register2 {count = 4}

  • Consider this execution interleaving with “count = 5” initially:

S0: producer execute register1 = count {register1 = 5}S1: producer execute register1 = register1 + 1 {register1 = 6} S2: consumer execute register2 = count {register2 = 5} S3: consumer execute register2 = register2 - 1 {register2 = 4} S4: consumer execute count = register2 {count = 4} S5: producer execute count = register1 {count = 6 }

  • If several processes are manipulating the same data concurrently, the outcome of the execution depends upon the particular order in which the access takes place
  • This situation is called a race condition
module 6 process synchronization
Process SynchronizationModule 6: Process Synchronization
  • Background
  • The Critical-Section Problem
  • Peterson’s Solution
  • Synchronization Hardware
  • Semaphores
  • Classic Problems of Synchronization
  • Monitors
  • Synchronization Examples
  • Atomic Transactions
critical section problem

Critical section – section of code changing common variables, updating a table or writing a file

Requirement for the system – the execution of critical sections by the processes must be mutually exclusive

Critical section Problem - To design a protocol that the processes can use to cooperate so as to allow execution of critical sections by the processes in mutually exclusive manner.

General structure of a typical process A.

do {

| entry section I request

critical section

I exit section I

remainder section

} while (TRUE);

Process Synchronization

Critical Section Problem
requirements for solution to critical section problem
Process SynchronizationRequirements for solution to Critical-Section Problem
  • Mutual Exclusion - If process Pi is executing in its critical section,

then no other processes can be executing in their critical sections.

  • Progress - If no process is executing in its critical section

some processes wish to enter

only processes which are not executing in its remainder section can make decision

and the selection cannot be postponed indefinitely

  • Bounded Waiting - A bound on the number of times that other

processes are allowed to enter their critical sections

after a process, Pi has made a request to enter

before that request is granted

    • Assume that each process executes at a nonzero speed
    • No assumption concerning relative speed of the N processes
two process solutions

Process numbered P0 and P1

Algorithm 1- common variable turn initialized to 0 or 1 if turn ==i, Process Pi is allowed to execute in its critical section

(states which process is allowed)

Process Synchronization

Two-Process Solutions

Process Pj [P1 ]

do {

while ( turn !=j);// Pi is not ready

CRITICAL SECTION

turn = i;

REMAINDER SECTION

}while(1)

Process Pi [P0 ]

do {

while ( turn != i );//Pj is not ready

CRITICAL SECTION

turn = j;

REMAINDER SECTION

}while(1)

Solution does not provide Progress Requirement

two process solutions1

Process numbered P0 and P1

Algorithm 1- common variable turn initialized to 0 or 1 if turn ==i, Process Pi is allowed to execute in its critical section

(states which process is allowed)

Process Synchronization

Two-Process Solutions

Process [P1]

do {

while ( turn !=1)

{ };// Pi is not ready

CRITICAL SECTION

turn = 0;

REMAINDER SECTION

}while(1)

Process [P0]

do {

while ( turn != 0 )

{ } ;//Pj is not ready

CRITICAL SECTION

turn = 1;

REMAINDER SECTION

}while(1)

Solution does not provide Progress Requirement

two process solutions2

Algorithm 2 – It remembers also the state of the process whether it has made a request

Uses boolean variable flag[2] initialized to 0

If flag[i] is true, denotes Pi is ready to enter into its critical section.

Process Synchronization

Two-Process Solutions

Process Pj [P1 ]

do {

flag[j] = true;

while (flag[i]); //Pi is not ready to enter

CRITICAL SECTION

flag[j] = false;

REMAINDER SECTION

} while(1)

Process Pi [P0 ]

do {

flag[i] = true;

while (flag[j]) { }; //Pj is not ready to enter

CRITICAL SECTION

flag[i] = false;

REMAINDER SECTION

} while(1)

two process solutions3

Algorithm 2 – Solution does not provide Progress Requirement

As the following execution sequence

[P0 ]sets flag[0] = true; then

[P1 ]sets flag[1] = true;

Causes both the processes looping forever in their respective while loops

Process Synchronization

Two-Process Solutions
module 6 process synchronization1
Process SynchronizationModule 6: Process Synchronization
  • Background
  • The Critical-Section Problem
  • Peterson’s Solution
  • Synchronization Hardware
  • Semaphores
  • Classic Problems of Synchronization
  • Monitors
  • Synchronization Examples
  • Atomic Transactions
peterson s solution algorithm 3
Process SynchronizationPeterson’s Solution / Algorithm 3
  • Assumptions- The LOAD and STORE instructions are atomic; that is, cannot be interrupted.
  • The two processes share two variables:
    • int turn;
    • Boolean flag[2]
  • The variable turn indicates whose turn it is to enter the critical section.
  • The flag array is used to indicate if a process is ready to enter the critical section.
  • flag[i] = true implies that process Pi is ready!
algorithm for processes
Process SynchronizationAlgorithm for Processes

Process Pj

do {

flag[j] = TRUE;

turn = i;

while ( flag[i] && turn == i);

CRITICAL SECTION

flag[j] = FALSE;

REMAINDER SECTION

} while (TRUE);

Process Pi

do {

flag[i] = TRUE;

turn = j;

while ( flag[j] && turn == j);

CRITICAL SECTION

flag[i] = FALSE;

REMAINDER SECTION

} while (TRUE);

  • The eventual value of turn decides which will enter CS first
  • It is correct solution meeting all the requirements
multiple process cs solutions

For n processes, the solution is called bakery algorithm.

  • Each Process wishing to enter into CS is given a number. Only the process with least number is allowed.
  • If two processes receive the same number their name is compared to break the tie.
  • Data structures used are
    • boolean choosing[n] initialized to false
    • Int number[n] initialized to 0
  • As the processes enter into CS on FCFS basis, it satisfies all its requirements

Process Synchronization

Multiple-Process CS Solutions
process p i in the bakery algorithm

do {

choosing[i] = true;

number[i] = max(number[0], number[1],……. number[n-1]) +1;

choosing[i] = false;

for(j=0 ; j < n ; j++) {

while(choosing[ j ]) { } ;

while( (number[j] != 0) && (number[ j ], j) < (number[ i ], i) { }; // Do nothing till there is another process, Pj with smaller number than Pi

}

CRITICAL SECTION

number[i] = 0;

REMAINDER SECTION

}while(1);

Process Synchronization

Process Piin the bakery algorithm
module 6 process synchronization2
Process SynchronizationModule 6: Process Synchronization
  • Background
  • The Critical-Section Problem
  • Peterson’s Solution
  • Synchronization Hardware
  • Semaphores
  • Classic Problems of Synchronization
  • Monitors
  • Synchronization Examples
  • Atomic Transactions
synchronization hardware
Process SynchronizationSynchronization Hardware
  • Many systems provide hardware support for critical section code
  • Uniprocessors – could disable interrupts
    • Currently running code would execute without preemption
    • Generally too inefficient on multiprocessor systems
  • Modern machines provide special atomic hardware instructions
      • Atomic = non-interruptable
      • Two instructions may execute simultaneously but sequentially in arbitrary order on different CPU’s
  • Hardware Instructions used -
    • TestAndSet - Either test memory word and set value
    • Swap -Or swap contents of two memory words
testandndset instruction
Process SynchronizationTestAndndSet Instruction

Test what is lock,

Set it to true

And

Return its previous value

  • Definition:

boolean TestAndSet (boolean *target)

{

boolean rv = *target;

*target = TRUE;

return rv:

}

solution using testandset
Process SynchronizationSolution using TestAndSet
  • Shared boolean variable lock., initialized to false.
  • The Lock value,

if False specified that the resource is not being utilized by any process,

if True then resource is in use so other processes have to wait, loop over

  • Solution:

do {

while ( TestAndSet (&lock ))

; /* do nothing

CRITICAL SECTION

lock = FALSE;

REMAINDER SECTION

} while ( TRUE);

swap instruction
Process SynchronizationSwap Instruction

Swap the boolean values

At

The locations specified by

Parameters, a & b

  • Definition:

void Swap (boolean *a, boolean *b)

{

boolean temp = *a;

*a = *b;

*b = temp:

}

solution using swap
Process SynchronizationSolution using Swap
  • Shared Boolean variable lock initialized to FALSE; Each process has a local Boolean variable key.
  • Solution:

do {

key = TRUE;

while ( key == TRUE)

Swap (&lock, &key ); // Keep swapping if lock is true

CRITICAL SECTION

lock = FALSE;

REMAINDER SECTION

} while ( TRUE);

  • Although these algorithms satisfy the mutual-exclusion requirement, they do not satisfy the bounded-waiting requirement.
module 6 process synchronization3
Process SynchronizationModule 6: Process Synchronization
  • Background
  • The Critical-Section Problem
  • Peterson’s Solution
  • Synchronization Hardware
  • Semaphores
  • Classic Problems of Synchronization
  • Monitors
  • Synchronization Examples
  • Atomic Transactions
semaphore
Process SynchronizationSemaphore
  • Synchronization tool that does not require busy waiting
  • Semaphore S – integer variable
  • Two standard atomic operations modify

wait() – wishes to use a resource also written as P() and

signal() – release a resource also written as V()

    • Originally called P() andV() from Dutch notation
  • The semaphore value in the wait() and signal() operations must be executed indivisibly
    • wait (S) {

while S <= 0

; // no-op

S--;

}

    • signal (S) {

S++;

}

Use:

Do {

wait(mutex);

CRITICAL SECTION

signal(mutex);

REMAINDER SECTION

} while(1);

other use of semaphores

For example, consider two concurrently running processes: P1 with a statement S1 and P2 with a statement S2.

Suppose we require that S2 be executed only after S1 has completed.

Let P1 and P2 share a common semaphore synch, initialized to 0, and

in process P1, S1;

signal(synch) ;

in process P2, wait(synch);

S2;

Process Synchronization

Other use of semaphores
semaphore as general synchronization tool
Process SynchronizationSemaphore as General Synchronization Tool
  • Counting semaphore – integer value can range over an unrestricted domain ( number of resources available)
  • Binary semaphore – integer value can have value 0 or 1

Also known as mutex locks

  • Provides mutual exclusion- Semaphore S; // initialized to 1
    • wait (S);

Critical Section

signal (S);

  • Can implement a counting semaphore S as a binary semaphore
semaphore implementation
Process SynchronizationSemaphore Implementation
  • Main Advantage of Semaphore? - To overcome the need for busy waiting, which is not adequate for uniprocessor systems, the process can use semaphore and block itself.
  • Executed indivisibly - Must guarantee that no two processes can execute wait () and signal () on the same semaphore at the same time
  • Thus, implementation becomes the critical section problem where the wait and signal code are placed in the critical section.
    • But implementation code is short
    • Little busy waiting if critical section rarely occupied
semaphore implementation with no busy waiting
Process SynchronizationSemaphore Implementation with no Busy waiting
  • With each semaphore there is an associated waiting queue. Each entry in a waiting queue has two data items:
    • value (of type integer)
    • pointer to next record in the list
  • Definition in C-

typedef struct {

int value; // semaphore value

struct process *list; // List of waiting processes

// which have to wait for resource

} semaphore;

  • Two operations:
    • Block() – place the process, P invoking the operation on the appropriate waiting queue.(adds )
    • Wakeup() – remove one of processes in the waiting queue and place it in the ready queue.(remove)
semaphore implementation with no busy waiting cont
Process SynchronizationSemaphore Implementation with no Busy waiting(Cont.)
  • Implementation of wait:

wait (S) {

value--;

if (value < 0) {

add this process to waiting queue

block(); } // suspends the process that invokes it

}

  • Implementation of signal:

Signal (S) {

value++;

if (value <= 0) {

remove a process P from the waiting queue

wakeup(P); //resumes the execution of the blocked process P

}

}

  • Basis : No two processes can execute the wait() and signal() operations on same semaphore at the same time
deadlock and starvation
Process SynchronizationDeadlock and Starvation
  • Implementation of a semaphore with waiting queue may result into deadlock
  • Deadlock : It is a situation where two or more processes are waiting indefinitely for an event that can be caused by only one of the waiting processes
  • Let S and Q be two semaphores initialized to 1

P0P1

wait (S); 1 wait (Q);

2 wait (S); // blocked

// blocked wait (Q); . .

Critical Section. Critical Section.

. .

signal (S); signal (Q);

signal (Q); signal (S);

  • Starvation – indefinite blocking. A process may never be removed from the semaphore queue, where it was added when it was suspended in wait(). (LIFO order)
module 6 process synchronization4
Process SynchronizationModule 6: Process Synchronization
  • Background
  • The Critical-Section Problem
  • Peterson’s Solution
  • Synchronization Hardware
  • Semaphores
  • Classic Problems of Synchronization
  • Monitors
  • Synchronization Examples
  • Atomic Transactions
classical problems of synchronization
Process SynchronizationClassical Problems of Synchronization
  • Bounded-Buffer Problem
  • Readers and Writers Problem
  • Dining-Philosophers Problem
bounded buffer problem
Process SynchronizationBounded-Buffer Problem
  • N buffers, each can hold one item
  • Semaphore mutex initialized to the value 1-

For mutual exclusion between two processes

  • Semaphore full initialized to the value 0 –

Denoting none buffer items are full till now.

  • Semaphore empty initialized to the value N –

Denoting N buffer items are empty till now.

bounded buffer problem cont
Process SynchronizationBounded Buffer Problem (Cont.)
  • The structure of the Producer process

do {

// produce an item

wait (empty); // decrement the no. of empty buffers

wait (mutex);

// add the item to the buffer

signal (mutex);

signal (full); // increment the no. of full buffers

} while (true);

bounded buffer problem cont1
Process SynchronizationBounded Buffer Problem (Cont.)
  • The structure of the consumer process

do {

wait (full); // decrement the no. of full buffers

wait (mutex);

// remove an item from buffer

signal (mutex);

signal (empty); // increment the no. of empty buffers

// consume the removed item

} while (true);

readers writers problem
Process SynchronizationReaders-Writers Problem
  • A data object is shared among a number of concurrent processes
    • Readers – only read the data object; 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.
  • Based on priorities, there are 2 forms of readers-writers problem:
    • No reader kept waiting until the writer has obtained permission to use the shared object
    • No writer kept waiting : Once a writer is ready, that writer performs its write as soon as possible & no new readers may start reading.
readers writers problem cont

1st Form - For no reader kept waiting until the writer has obtained permission to use the shared object. Only after all readers finish reading, writers are allowed to write.

  • 2nd Form - For no writer kept waiting until there is another writer which has obtained permission to write. If readers are reading then writer gets the chance to write immediately after they complete and no new readers entertained.
  • Shared Data
  • Shared data object
  • Semaphore mutex initialized to 1. It is used to ensure mutual exclusion when the variable readcount is updated. (For reader process only)
  • Semaphore wrt initialized to 1. It functions as a mutual -exclusion semaphore for the writers. (Used by both processes)
  • Integer readcount initialized to 0. The readcount variable keeps track of how many processes are currently reading the object.

Process Synchronization

Readers-Writers Problem (Cont.)
readers writers problem 1 st form
Process SynchronizationReaders-Writers Problem- 1st Form

Reader process

do {

wait (mutex) ;

readcount ++ ;

if (readercount == 1)

wait (wrt) ;

signal (mutex)

// reading is performed

wait (mutex) ;

readcount - - ;

if redacount == 0)

signal (wrt) ;

signal (mutex) ;

} while (true)

Writer process

do {

wait (wrt) ;

// writing is performed and so wrt made 0

signal (wrt) ;

} while (true)

Multiple readers allowed to read at the same time

Multiple writers can’t write at the same time

dining philosophers problem
Process SynchronizationDining-Philosophers Problem
  • Shared data
    • Bowl of rice (data set)
    • Semaphore chopstick [5] initialized to 1
    • As usual wait() to grab the chopstick and signal() to release
dining philosophers problem cont
Process SynchronizationDining-Philosophers Problem (Cont.)
  • The structure of Philosopher i for no two neighbors eating simultaneously,

Do {

wait ( chopstick[i] );

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

// eat

signal ( chopstick[i] );

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

// think

} while (true) ;

  • It has the possibility of creating a deadlock.
problems with semaphores
Process SynchronizationProblems with Semaphores
  • Incorrect use of semaphore operations:
    • signal (mutex) …. wait (mutex) //multiple processes in CS
    • wait (mutex) … wait (mutex) // deadlock will occur
    • Omitting of wait (mutex) or signal (mutex) (or both)
  • Use high level synchronization construct
    • Conditional Critical region
    • Monitors
ad