Scribd
Upload
4 views24 pages

Blocking Synchronization: Semaphores Condition Regions Monitors

The document discusses blocking synchronization mechanisms, specifically semaphores, critical regions, and monitors. It explains semaphore operations, including the P (wait) and V (signal) functions, as well as the characteristics of binary and counting semaphores. Additionally, it covers the concept of monitors, their semantics, and the differences between Hoare and Hansen monitors, highlighting their trade-offs in programming and synchronization efficiency.

Uploaded by

Tuấn Hoàng Văn
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
4 views24 pages

Blocking Synchronization: Semaphores Condition Regions Monitors

The document discusses blocking synchronization mechanisms, specifically semaphores, critical regions, and monitors. It explains semaphore operations, including the P (wait) and V (signal) functions, as well as the characteristics of binary and counting semaphores. Additionally, it covers the concept of monitors, their semantics, and the differences between Hoare and Hansen monitors, highlighting their trade-offs in programming and synchronization efficiency.

Uploaded by

Tuấn Hoàng Văn
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 24

Blocking Synchronization

Semaphores
Condition regions
Monitors
Semaphores

A semaphore consists of:


A variable v
A thread list L
A function P (wait)
A function V (signal)

syntax example: Semaphore s(5);


Semaphore Operations

Initialization(val)
{
v = val ;
L = ^;
}
P(s)

v--;
if(v < 0)
{
add thread to L;
block;
}
This code executes atomically.
V(s)

v++;
if(v £ 0)
{
Remove a thread T from L;
Unblock(T);
}
This code executes atomically.
Important Properties

V(s) never blocks


The insertion and removal from L can be done at random.
In practice, FIFO is mostly used, transforming the list into a
queue.
The value v gives how many processes are allowed in.
Binary Semaphore

Two types:
Counting semaphores
v takes any values
Binary semaphores
v takes only 0 or 1
P(s): Binary Semaphores

if(v == 0) executes
{ atomically
Add caller to L;
Block;
}
else
v--;
V(s): Binary Semaphores

if(L != ^) does not


{ block
Remove a thread T from L;
Unblock(T);
}
else if(v == 0)
v = 1;
Critical Regions

Also known as: Condition regions


It consists of
A mutex variable v
A condition B (also called guarding condition)
A statement S
Syntax & Semantics

region v when B do S ;

When a thread acquires v, no other thread can access any


region protected by v
If a thread acquires v, the statement S is executed if B is true
If B is not true, thread gives up v, and blocks
When B becomes true, a blocked thread wakes up, tries to
acquire v and repeat the test
Example

x = 0; Thread T1, T2

region v when x > 1 do region v when x < 1 do


S1; S2;
region v when true do x = 4;
S4; region v when true do
S3;

What are the possible orders of S1, S2, S3 & S4?


Implementation Issues

Guarding condition is not made out of special variables


Compiler must track when the condition becomes true and re-
evaluate it so that a waiting thread can get in.
Almost impossible to do with any hope of efficiency using
existing technology.
Monitors (late 60’s, early 70’s)

A programming language construct, much like what we call


today objects
Consists of:
General purpose variables
Methods
Initialization code (constructor)
Condition variables
Example Declaration

Monitor M {
int a, b, c ;
condition x, y, z ;
fn1(…);
fn2(…);
…
fnm(…);}
Example Declaration (cont’d)

M(…)
{
/* initialization code */
}

Like a C++ constructor, of sort...


Semantics

Only one method within the monitor could be active at a time


Condition variables have two operations:
x.wait
Calling thread blocks, gives up monitor
Wait on a queue until someone signals variable
x.signal
Unblock someone who was waiting on the variable
Hoare Monitors

Assume thread Q waiting on condition x


Assume thread P is in the monitor
Assume thread P calls x.signal
P gives up monitor, P blocks!
Q takes over monitor, runs
Q finishes, gives up monitor
P takes over monitor, resumes
Per Brinch Hansen’s Monitors

Assume thread Q waiting on condition x


Assume thread P is in the monitor
Assume thread P calls x.signal
P continues, finishes
Q takes over monitor, runs
Q finishes, gives up monitor
Example: Hoare Monitors

fn1(…)
…
x.wait // T1 blocks fn4(…)
…
x.signal // T2 blocks
// T1 resumes
// T1 finishes
// T2 resumes
Example: Hansen Monitors

fn1(…)
…
x.wait // T1 blocks fn4(…)
…
x.signal // T2 continues
// T2 finishes
// T1 resumes
// T1 finishes
Tradeoff

Hoare Hansen
Awkward in programming Easier to program
Cleaner, good for Can lead to synchronization
mathematical proofs bugs
Main advantage: when a
condition variable is
signalled, condition does
not change
Example

fn()
{
…
x.signal
}
A Hoare monitor forces thread to block needlessly in
this example
Example: Java

Each object has a monitor


User can specify the keyword “synchronized” in front of
methods that must execute with mutual exclusion

You might also like