Top Banner
Process Synchronization Ch. 4.4 – Cooperating Processes Ch. 7 – Concurrency
22

Process Synchronization Ch. 4.4 – Cooperating Processes Ch. 7 – Concurrency.

Dec 22, 2015

Download

Documents

Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: Process Synchronization Ch. 4.4 – Cooperating Processes Ch. 7 – Concurrency.

Process Synchronization

Ch. 4.4 – Cooperating ProcessesCh. 7 – Concurrency

Page 2: Process Synchronization Ch. 4.4 – Cooperating Processes Ch. 7 – Concurrency.

Cooperating Processes

Independent process cannot affect or be affected by the execution of another process.

Cooperating process can affect or be affected by the execution of another process

Page 3: Process Synchronization Ch. 4.4 – Cooperating Processes Ch. 7 – Concurrency.

Advantages of process cooperation

Information sharing • Allow concurrent access to data sources

Computation speed-up• Sub-tasks can be executed in parallel

Modularity• System functions can be divided into separate

processes or threads Convenience

Page 4: Process Synchronization Ch. 4.4 – Cooperating Processes Ch. 7 – Concurrency.

Context Switches can Happen at Any Time

A process switch (full context switch) can happen at any time there is a mode switch into the kernel

This could be because of a:• System call (semi-predictable)• Timer (round robin, etc.)• I/O interrupt (unblock some other process)• Other interrupt, etc.

The programmer generally cannot predict at what point in a program this might happen

Page 5: Process Synchronization Ch. 4.4 – Cooperating Processes Ch. 7 – Concurrency.

Preemption is Unpredictable

This means that the program’s work can be interrupted at any time (I.e. just after the completion of any instruction):• Some other program gets to run for a while

• And the interrupted program eventually gets restarted exactly where it left off.

• After the other program (process) executes other instructions that we have no control over

This can lead to trouble if processes are not independent

Page 6: Process Synchronization Ch. 4.4 – Cooperating Processes Ch. 7 – Concurrency.

Problems with Concurrent Execution

Concurrent processes (or threads) often need to share data (maintained either in shared memory or files) and resources

If there is no controlled access to shared data, execution of the processes on these data can interleave.

The results will then depend on the order in which data were modified • i.e. the results are non-deterministic.

Page 7: Process Synchronization Ch. 4.4 – Cooperating Processes Ch. 7 – Concurrency.

Shared Memory

kernel

process B

process A

shared memory

Page 8: Process Synchronization Ch. 4.4 – Cooperating Processes Ch. 7 – Concurrency.

An Example: Bank Account

A joint account. Each account holder accesses money at the same time – one deposits, the other withdraws.

The bank’s computer is executing the routine below simultaneously as two processes running the same transaction processing program

void update(acct,amount){ temp = getbalance(acct); temp += amount; putbalance(acct,temp);}

Page 9: Process Synchronization Ch. 4.4 – Cooperating Processes Ch. 7 – Concurrency.

Banking Examplevoid update(acct,amount){ temp = getbalance(acct); temp += amount; putbalance(acct,amount);}

temp = 60temp = 60 + 100putbalance (160)

Initial balance = $60A’s deposit = $100B’s withdrawal = $50Net balance = $110

A’s process:

Process Switch!

Process Switch!

B’s process:

temp = 60 - 50putbalance (10)

temp = 60

What is the final bank balance?

Page 10: Process Synchronization Ch. 4.4 – Cooperating Processes Ch. 7 – Concurrency.

Race Conditions

A situation such as this, where processes “race” against each other, causing possible errors, is called a race condition.

2 or more processes are reading/writing shared data and the final result depends on the order the processes have run

Can happen at the application level and the OS level

Page 11: Process Synchronization Ch. 4.4 – Cooperating Processes Ch. 7 – Concurrency.

Printer queue example (OS level)

Printer queue – often implemented as a circular queue.• Out = position of next item to be printed

• In = position of next empty slot. lw or lpr

• File added to print queue What happens if 2 processes requesting

queuing of a print job at the same time? Each must access the variable “in”.

Page 12: Process Synchronization Ch. 4.4 – Cooperating Processes Ch. 7 – Concurrency.

Dueling queueing

Timeline (Process A)

1. Read in = 7

2.

3.

4.

5.

6. Insert job at position 7

7. in++ (in = 8)

8. Exit lw

Timeline (Process B)

1.

2. Read in = 7

3. Insert job at position 7

4. in++ (in = 8)

5. Exit lw

6.

7.

8.

What happened to B’s print job?

Page 13: Process Synchronization Ch. 4.4 – Cooperating Processes Ch. 7 – Concurrency.

Producer-Consumer Problem

Paradigm for cooperating processes, producer process produces information that is consumed by a consumer process.• unbounded-buffer places no practical limit on

the size of the buffer.

• bounded-buffer assumes that there is a fixed buffer size.

Print queue is an example – processes putting jobs in queue, printer daemon taking jobs out.• Daemon = process that runs continually and

handles service requests

Page 14: Process Synchronization Ch. 4.4 – Cooperating Processes Ch. 7 – Concurrency.

Basic Producer-Consumer

Producer

repeat

produce item /*if buffer full, do nothing*/

while (counter ==n);

insert item

counter ++;

forever

Consumer

repeat /* if buffer empty, do nothing*/

while (counter ==0);

remove item

counter--;

consume item

forever

Shared data: (bounded buffer)Buff size = nCounter = 0

Page 15: Process Synchronization Ch. 4.4 – Cooperating Processes Ch. 7 – Concurrency.

Problems with Basic algorithm

More than 1 process can access shared “counter” variable

Race condition can result in incorrect value for “counter”

Inefficient:• Busy-wait checking value of counter

Page 16: Process Synchronization Ch. 4.4 – Cooperating Processes Ch. 7 – Concurrency.

Producer-Consumer with Sleep

Producer

repeat

produce item

/*if buffer full, go to sleep*/

if (counter ==n)

sleep();

insert item

counter ++;

If (count ==1)

wakeup(consumer);

forever

Consumer

repeat

/* if buffer empty, go to sleep*/

if (counter ==0)

sleep();

remove item

counter--;

if (count ==(n-1)

wakeup (producer)

consume item

forever

Shared data: (bounded buffer)Buff size = nCounter = 0

Page 17: Process Synchronization Ch. 4.4 – Cooperating Processes Ch. 7 – Concurrency.

Problems

If counter has a value of 1..n-1, both processes are running, so both can access shared “counter” variable

Race condition can result in incorrect value for “counter”

Could lead to deadlock with both processes asleep

Page 18: Process Synchronization Ch. 4.4 – Cooperating Processes Ch. 7 – Concurrency.

Could also lead to deadlock…

Timeline (Consumer)

1. If (counter ==0) True

2.

3.

4.

5.

6.

7.

8. Sleep()

Timeline (Producer)

1.

2. Produce item

3. If (counter ==n) F

4. Insert item

5. Counter++

6. If (counter == 1) T

7. Wakeup (consumer)

8.

Wakeup call lost as consumer not sleepingEventually both will be asleep - deadlock

Page 19: Process Synchronization Ch. 4.4 – Cooperating Processes Ch. 7 – Concurrency.

Critical section

That part of the program where shared resources are accessed

When a process executes code that manipulates shared data (or resource), we say that the process is in a critical section (CS) (for that resource)

Entry and exit sections (small pieces of code) guard the critical section

Page 20: Process Synchronization Ch. 4.4 – Cooperating Processes Ch. 7 – Concurrency.

The Critical Section Problem

CS’s can be thought of as sequences of instructions that are ‘tightly bound’ so no other process should interfere via interleaving or parallel execution.

The execution of CS’s must be mutually exclusive: At any time, only one process should be allowed to execute in a CS (even with multiple CPUs)

Therefore we need a system where each process must request permission to enter its CS, and we need a means to “administer” this

Page 21: Process Synchronization Ch. 4.4 – Cooperating Processes Ch. 7 – Concurrency.

The Critical Section Problem The section of code implementing this request

is called the entry section The critical section (CS) will be followed by an

exit section, which opens the possibility of other processes entering their CS.

The remaining code is the remainder section RS

The critical section problem is to design the processes so that their results will not depend on the order in which their execution is interleaved.

We must also prevent deadlock and starvation.

Page 22: Process Synchronization Ch. 4.4 – Cooperating Processes Ch. 7 – Concurrency.

Framework for analysis of solutions Each process

executes at nonzero speed but no assumption on the relative speed of n processes

General structure of a process:

Several CPUs may be present but memory hardware prevents simultaneous access to the same memory location

No assumptions about order of interleaved execution

The central problem is

to design the entry and exit sections

repeat entry section critical section exit section remainder sectionforever