Lecture 05 Probs Of Concurrent Process

Real-Time Operating Systems B.Sc. Special Honors Degree in Computer Systems and Networking Koliya Pulasinghe B.Sc.Eng.(Hons.), Ph.D., MIET, MIEEE Sri Lanka Institute of Information Technology [email_address] +94 011 2413900

Objectives :

Discuss problems in concurrent processes

Discuss the critical section problem

Discuss solutions for critical-section problems using Semaphores, etc

What is process Synchronization?

A cooperating process is one that affect or be affected by the other processes executing in the system.

Cooperating processes may share

- both code & data (threads)

- data through files.

Concurrent access to shared data may result in data inconsistency.

Orderly execution of processes without violating the data inconsistency is process synchronization.

Example The producer/consumer problem:

Producer : produces information.

Consumer : consumes information.

Bounded buffers (Circular list ).

in -> next free buffer.

out -> first full buffer.

empty -> in = out.

The producer/consumer problem:

Shared data var n;

Type item = … ;

var buffer: array [0..n-1] of item;

nextp, nextc : item;

in, out: 0 .. n-1;

counter: 0 .. n;

in, out, counter = 0;

In Out

Producer process

repeat

…

produce an item in nextp ;

…

while ( counter = n) do no-op ;

/* busy waiting */

buffer [ in ] := nextp ;

in = ( in +1) mod n ;

counter := counter + 1;

until false ;

This counter variable also appears in consumer process

Consumer process

repeat

while ( counter = 0) do no-op ;

nextc := buffer [ out ];

out = ( out +1) mod n ;

counter := counter –1;

…

consume item in nextc ;

…

until false ;

There is a problem.

The statements counter++; counter--; must be performed atomically . :as one uninterruptible unit.

Atomic operation means an operation that completes in its entirety without interruption.

What is the problem?

Example

Suppose the current value of counter = 5; concurrently:

producer executes counter = counter +1; and

consumer executes counter = counter –1;

The value of counter can be 4, 5, or 6; while the correct answer should be 5 (if the producer and consumer executes separately).

How the problem occurs?

The statement “ count++ ” may be implemented in machine language as: register1 = counter

register1 = register1 + 1 counter = register1

The statement “ count-- ” may be implemented as: register2 = counter register2 = register2 – 1 counter = register2

How the problem occurs?

Assume counter is initially 5.

producer: register1 = counter ( register1 = 5 )

producer: register1 = register1 + 1 (register1 = 6)

consumer: register2 = counter (register2 = 5)

consumer: register2 = register2 – 1 (register2 = 4)

producer: counter = register1 (counter = 6)

consumer: counter = register2 (counter = 4)

Incorrect result because we allowed both processes to manipulate counter concurrently.

Race Condition

Race condition: The situation where several processes access and manipulate same (shared) data concurrently . The final value of the shared data depends on particular order in which the access takes place.

In order to prevent race condition on counter, we need to ensure that only one process at a time can be manipulating the variable counter

For this, concurrent processes must be synchronized .

The Critical-Section Problem

n processes {P 0 , P 1 , … , P n-1 } 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 P i

Repeat

Entry section .

Critical section.

Exit section .

Remainder section.

Until false;

Solution to Critical-Section Problem

Mutual Exclusion:

If process P i is executing in its critical section, then no other processes can be executing in their critical sections.

or

No processes may be simultaneously inside their critical sections.

Progress:

If no process is in its critical section and there exists some processes that wish to enter their critical sections, then only processes not in their remainder section can participate in the decision as to which one enters its critical section next, and this selection cannot be postponed indefinitely

or

No process running outside its critical section may block other processes.

Bounded Waiting:

There must exist a bound on the number of times that other processes can enter their critical section after a process has made a request to enter its critical section and before that request is granted;

or

No process should have to wait forever to enter its critical section.

Simplest solution:

Each process disable all interrupts just after entering its critical section and re-enable them just before leaving it With interrupts disabled, no clock interrupts can occur.

The CPU is only switched from process to process as a result of clock or other interrupts.

With interrupts turned off the CPU will not be switched to another process.

This simple solution has problems.

Problems

Unwise to give user processes the power to turn off interrupts.

Suppose one of them did it, and never turned them on again? That could be the end of the system.

If the computer has two or more CPUs, disabling interrupts affects only the CPU that executed the disable instruction. The other will continue running and can access shared memory.

Therefore not good solution for multi processor environment.

Initial Attempts to Solve Problem

Only 2 processes, P 0 and P 1

General structure of process Pi (other process Pj )

do {

entry section

critical section

exit section

reminder section

} while (1);

Processes may share some common variables to synchronize their actions.

Primary solution:Lock Variables

This is a software solution for process synchronization.

Have a single , shared ( lock ) variable, initially 0.

When a process wants to enter its critical region, it first test the lock. If the lock is 0, the process sets it to 1 and enters the critical region. If the lock is already 1, the process just waits until it becomes 0.

But this method has a problem.

Problem with the lock

Suppose one process reads the lock and sees that it is 0.

Before it can set the lock to 1, another process is scheduled, runs, and sets the lock to 1.

When the first process runs again, it will also set the lock to 1, and the two processes will be their critical regions at the same time.

Following algorithm tackles this problem and meets all three conditions.

Algorithm

Process P i

repeat

flag [ i ] = true ;

turn = j ;

while ( flag [ j ] and turn = j ) do no-op ;

critical section

flag [ i ] = false ;

remainder section

until false ;

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

Semaphores

It’s a tool that provide solutions for synchronization problems.

Semaphore S – integer variable.

Two standard operations modify S: wait() and signal()

Originally called P() and V()

Less complicated

Can only be accessed via two indivisible (atomic) operations

P(S) or wait(S): while S ≤0 do no-op; S := S - 1; V(S) or signal (S): S := S + 1; Can be used to solve the n-process critical section problem.

Shared variables

var mutex: semaphore;

/* initially mutex = 1 */

Process Pi: repeat wait(mutex); Critical Section signal(mutex); Remainder Section until false; Note, the classical definition still requires a busy waiting.

Semaphores(contd.)

Thus, implementation becomes the critical section problem where the wait and signal code are placed in the critical section.

Could now have busy waiting in critical section implementation

But implementation code is short

Little busy waiting if critical section rarely occupied

Note that applications may spend lots of time in critical sections and therefore this is not a good solution.

This type of semaphore is called spinlock.

Semaphores(contd.)

To overcome the need for busy waiting we can modify the definition of the wait and signal semaphore operations.

When a process executes the wait operation and find that semaphore value is not positive, it must wait.

However,rather than busy waiting, the process can block itself.

The block operation places a process into a waiting queue associated with the semaphore, and the state of the process is switched to the waiting state

Semaphores(contd.)

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

Two operations:

block – place the process invoking the operation on the appropriate waiting queue.

wakeup – remove one of processes in the waiting queue and place it in the ready queue.

Semaphores(contd.)

Then control is transferred to the CPU scheduler, which selects another process to execute.

A process that is blocked, waiting on a semaphore S, should be restarted when some other process executes signal operation.

The process is restarted by a wakeup operation, which changes the process from the waiting state to the ready state. The process is then placed in the ready queue.