Notes on High-Level Synchronization - Chapter 9 - Operating Systems | CS 3204, Study notes of Operating Systems

Download Notes on High-Level Synchronization - Chapter 9 - Operating Systems | CS 3204 and more Study notes Operating Systems in PDF only on Docsity!

Chapter 9

High-level Synchronization

Introduction to Concurrency

n Concurrency

n Execute two or more pieces of code "at the same time“ n Why? n No choice: n Geographically distributed data n Interoperability of different machines n A piece of code must "serve" many other client processes n To achieve reliability n By choice: n To achieve speedup n Sometimes makes programming easier (e.g., UNIX pipes)

Examples of Concurrency

in Uniprocessors

Example 1: Unix pipes Motivations:

• fast to write code
• fast to execute Example 2: Buffering Motivation:
• required when two asynchronous processes must communicate Example 3: Client/Server model Motivation:
• geographically distributed computing

Operating System issues to

Support Concurrency

n Synchronization

n What primitives should OS provide?

n Communication

n What primitives should the OS provide to the interface communication protocol?

n Hardware Support

n Needed to implement OS primitives

Definitions

n Concurrent process execution can be:

n interleaved, or n physically simultaneous

n Interleaved

n Multi-programming on uniprocessor

n Physically simultaneous

n Uni- or multi-programming on multiprocessor

Definitions…

n Process, thread, or task

n Scheduleable unit of computation

n Granularity

n Process "size" or computation to n Communication ratio n Too small: excessive overhead n Too large: less concurrency

Cyclic Precedence Graph

Precedence Graphs must

be ACYCLIC

Precedence Graphs must

be ACYCLIC

S

S

S

What does the following graph represent?

S2 must be performed before S3 begins

AND

S3 must be performed before S2 begins

Concurrency Conditions

Read set of Si: R (Si) = { a1, a2, ..., an } Set of all variables referenced in Si

Write set of Si: W (Si) = { b1, b2, ..., bm }, Set of all variables changed by Si

Let Si denote a statement.

Bernstein's Conditions

The following conditions must hold for two statements S1 and S2 to execute concurrently with valid results:

1) R ( S1 ) INTERSECT W ( S2 ) = { }

2) W ( S1 ) INTERSECT R ( S2 ) = { }

3) W ( S1 ) INTERSECT W ( S2 ) = { }

These are called the Bernstein Conditions.

Parallel Language Constructs (Review)

FORK and JOIN FORK and JOIN FORK L Starts parallel execution at the statement labelled L and at the statement following the FORK

JOIN Count Recombines 'Count' concurrent computations

Count := Count - 1; If ( Count > 0 ) Then Terminate computation Join is an atomic operation. else continue

Parbegin / Parend

Examples

Begin PARBEGIN A := X + Y; B := Z + 1; PAREND; C := A - B; W := C + 1; End;

Begin PARBEGIN A := X + Y; B := Z + 1; PAREND; C := A - B; W := C + 1; End;

Begin S1; PARBEGIN S3; BEGIN S2; S4; PARBEGIN S5; S6; PAREND; End; PAREND; S7; End;

Begin S1; PARBEGIN S3; BEGIN S2; S4; PARBEGIN S5; S6; PAREND; End; PAREND; S7; End;

Synchronization with Monitors

Condition Variables

n Within the monitor, Condition Variables are declared n A queue is associated with each condition variable n Only two operations are allowed on a condition variable: The procedure performing the wait is put on the queue associated with x If queue is non-empty: resume some process at the point it was made to wait

X.wait X.signal

• Note: V operations on a semaphore are "remembered," but if there are no waiting processes, the signal has no effect
• OS scheduler decides which of several waiting monitor calls to unlock upon signal

Monitor…

ADT’s condition variables Proc1 queues Proc Proc

queue

ßQueue to enter monitor via calls to procedures ßQueues within the monitors via condition variables ßADTs and condition variables only accessible via monitor procedure calls