You are on page 1of 56

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 Advantages of process cooperation
Information sharing Computation speed-up Modularity Convenience

Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved. 0-13-142938-8

Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved. 0-13-142938-8

Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved. 0-13-142938-8

Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved. 0-13-142938-8

Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved. 0-13-142938-8

Figure 2-8 Two processes want to access shared memory at the same time.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved. 0-13-142938-8

Problems with Concurrent Execution


 Concurrent processes often need to share data (maintained either in shared memory or files) and resources If there is no controlled access to shared data, some processes may obtain an inconsistent view of data Non-determinism: the action performed by concurrent processes will depend on the order in which their execution is interleaved

 

Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved. 0-13-142938-8

Race Conditions
 Situations where processes access the same data concurrently and the outcome of execution depends on the particular order in which the access takes place are called race conditions How can processes coordinate (or synchronise) in order to guard against race conditions?

Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved. 0-13-142938-8

The Critical Section Problem


 When a process executes code that manipulates shared data (or resource), we say that the process is in its critical section (for that shared data) The execution of critical sections must be mutually exclusive: at any time: only one process is allowed to execute in its critical section (even with multiple CPUs) Each process must request the permission to enter a critical section

Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved. 0-13-142938-8

Critical Sections
Necessary to avoid race conditions: 1. No two processes may be simultaneously inside their critical regions. 2. No assumptions may be made about speeds or the number of CPUs. 3. No process running outside its critical region may block other processes. 4. No process should have to wait forever to enter its critical region.

Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved. 0-13-142938-8

Mutual Exclusion with Busy Waiting

Figure 2-9 Mutual exclusion using critical regions.


Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved. 0-13-142938-8

Strict Alternation

Figure 2-10. A proposed solution to the critical region problem. (a) Process 0. (b) Process 1. In both cases, be sure to note the semicolons terminating the while statements.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved. 0-13-142938-8

Definitions
critical section : a section of code that reads/writes (CS) shared data

race condition:

potential for interleaved execution of a critical section by

multiple threads => results are non-deterministic

mutual exclusion: synchronization mechanism to avoid (ME) race conditions by ensuring exclusive execution of critical sections

Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved. 0-13-142938-8

Petersons Solution (1)

{ ...

Figure 2-11 Petersons solution for achieving mutual exclusion.


Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved. 0-13-142938-8

Petersons Solution (2)

Figure 2-11 Petersons solution for achieving mutual exclusion.


Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved. 0-13-142938-8

The TSL Instruction

Figure 2-12. Entering and leaving a critical region using the TSL instruction.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved. 0-13-142938-8

Mutual Exclusion Machine Instructions

Disadvantages
Busy-waiting consumes processor time Starvation is possible when a process leaves a critical section and more than one process is waiting. Deadlock
If a low priority process has the critical region and a higher priority process needs it, the higher priority process will obtain the processor just to wait for the critical region

Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved. 0-13-142938-8

The Producer-Consumer Problem (1)

... Figure 2-13. The producer-consumer problem with a fatal race condition.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved. 0-13-142938-8

The Producer-Consumer Problem (2)


...

Figure 2-13. The producer-consumer problem with a fatal race condition


Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved. 0-13-142938-8

OS Solutions: Semaphores
Synchronization tool (provided by the OS) that does not require busy waiting A semaphore S is an integer variable that, apart from initialization, can only be accessed through 2 atomic and mutually exclusive operations: Up (S) Down (S) Avoids busy waiting when a process has to wait, the OS will put it in a blocked queue of processes waiting for that semaphore

Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved. 0-13-142938-8

The Producer-Consumer Problem (3)

...

Figure 2-14. The producer-consumer problem using semaphores.


Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved. 0-13-142938-8

The Producer-Consumer Problem (4)


...

Figure 2-14. The producer-consumer problem using semaphores.


Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved. 0-13-142938-8

Binary Semaphores
Similar to general (counting) semaphores except that count is Boolean valued Counting semaphores can be implemented using binary semaphores More difficult to use than counting semaphores (eg: they cannot be initialized to an integer k > 1)

Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved. 0-13-142938-8

Problems with Semaphores


Semaphores are a powerful tool for enforcing mutual exclusion and coordinate processes Problem: wait(S) and signal(S) are scattered among several processes It is difficult to understand their effects Usage must be correct in all processes One bad (or malicious) process can fail the entire collection of processes

Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved. 0-13-142938-8

Monitors
Are high-level language constructs that provide equivalent functionality to semaphores but are easier to control

Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved. 0-13-142938-8

Monitors
Is a software module containing: one or more procedures an initialization sequence local data variables Characteristics: local variables accessible only by monitors procedures a process enters the monitor by invoking one of its procedures only one process can be in the monitor at any one time

Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved. 0-13-142938-8

Monitors
The monitor ensures mutual exclusion no need to program this constraint explicitly Shared data are protected by placing them in the monitor The monitor locks the shared data on process entry Process synchronization is done using condition variables, which represent conditions a process may need to wait for before executing in the monitor

Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved. 0-13-142938-8

Condition Variables
Local to the monitor (accessible only within the monitor) Can be access and changed only by two functions: wait(a): blocks execution of the calling process on condition (variable) a the process can resume execution only if another process executes signal(a) signal(a): resume execution of some process blocked on condition (variable) a. If several such process exists: choose any one If no such process exists: do nothing

Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved. 0-13-142938-8

Monitors
Awaiting processes are either in the entrance queue or in a condition queue A process puts itself into condition queue cn by issuing wait(cn) signal(cn) brings into the monitor one process in condition cn queue signal(cn) blocks the calling process and puts it in the urgent queue (unless signal is the last operation of the monitor procedure)

Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved. 0-13-142938-8

Monitors (1)

Figure 2-15. A monitor.


Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved. 0-13-142938-8

Monitors (2)

Figure 2-16. An outline of the producer-consumer problem with monitors. Only one monitor procedure at a time is active. The buffer has N slots
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved. 0-13-142938-8

Monitors (3)

Figure 2-16. An outline of the producer-consumer problem with monitors. Only one monitor procedure at a time is active. The buffer has N slots
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved. 0-13-142938-8

Message Passing
Send( destination , &message); Receive( source , &message);

Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved. 0-13-142938-8

Message Passing (1)

... Figure 2-17. The producer-consumer problem with N messages.


Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved. 0-13-142938-8

Message Passing (2)


...

Figure 2-17. The producer-consumer problem with N messages.


Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved. 0-13-142938-8

The Dining Philosophers Problem (1)

Figure 2-18. Lunch time in the Philosophy Department.


Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved. 0-13-142938-8

The Dining Philosophers Problem (2)

Figure 2-19. A nonsolution to the dining philosophers problem.


Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved. 0-13-142938-8

The Dining Philosophers Problem (3)

...

Figure 2-20. A solution to the dining philosophers problem.


Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved. 0-13-142938-8

The Dining Philosophers Problem (4)


...

... Figure 2-20. A solution to the dining philosophers problem.


Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved. 0-13-142938-8

The Dining Philosophers Problem (5)


...

Figure 2-20. A solution to the dining philosophers problem.


Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved. 0-13-142938-8

The Readers and Writers Problem (1)

... Figure 2-21. A solution to the readers and writers problem.


Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved. 0-13-142938-8

The Readers and Writers Problem (2)


...

Figure 2-21. A solution to the readers and writers problem.


Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved. 0-13-142938-8

Threads (1)

Figure 2-6 (a) Three processes each with one thread.


Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved. 0-13-142938-8

Threads (2)

Figure 2-6 (b) One process with three threads.


Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved. 0-13-142938-8

Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved. 0-13-142938-8

Benefits

Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved. 0-13-142938-8

Multithreading Models

Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved. 0-13-142938-8

Many to One

Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved. 0-13-142938-8

One to One

Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved. 0-13-142938-8

Many to Many

Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved. 0-13-142938-8

Threads (3)

Figure 2-7. The first column lists some items shared by all threads in a process. The second one lists some items private to each thread.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved. 0-13-142938-8

Thread Scheduling (1)

(a)

Figure 2-28. (a) Possible scheduling of user-level threads with a 50-msec process quantum and threads that run 5 msec per CPU burst.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved. 0-13-142938-8

Thread Scheduling (2)

(b)

Figure 2-28. (b) Possible scheduling of kernel-level threads with the same characteristics as (a).
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved. 0-13-142938-8

Deadlocks

Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved. 0-13-142938-8

Deadlock
Permanent blocking of a set of processes that either compete for system resources or communicate with each other Involves conflicting needs for resources by two or more processes There is no satisfactory solution in the general case Some OSes (ex: Unix SVR4) ignore the problem and pretend that deadlocks never occur...

Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved. 0-13-142938-8

Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved. 0-13-142938-8