Shared Memory

Model
Giuseppe Anastasi
[email protected]
Pervasive Computing & Networking Lab. (PerLab)
Dept. of Information Engineering, University of Pisa

PerLab

Partially based on original slides by Silberschatz, Galvin and Gagne

Overview
PerLab

The Critical-Section Problem

Software Solutions
Synchronization Hardware
Semaphores
Monitors
Synchronization Examples

Shared Memory Model

Objectives
PerLab

To introduce the critical-section problem, whose

solutions can be used to ensure the consistency
of shared data
To present both software and hardware solutions
of the critical-section problem

Shared Memory Model

Overview
PerLab

The Critical-Section Problem

Software Solutions
Synchronization Hardware
Semaphores
Monitors
Synchronization Examples

Shared Memory Model

Producer-Consumer Problem
PerLab

The Producer process produces data that must

processed by the Consumer Process
The inter-process communication occurs through
a shared buffer (shared memory)
Bounded Buffer Size
The producer process cannot insert a new item if the
buffer is full
The Consumer process cannot extract an item if the
buffer is empty

Shared Memory Model

Producer-Consumer Problem
PerLab

Shared data
#define BUFFER_SIZE 10
typedef struct {
...
} item;
item buffer[BUFFER_SIZE];
int in = 0;
int out = 0;
int counter = 0;

Shared Memory Model

Producer-Consumer Problem
PerLab

Producer process
item nextProduced;
while (1) {
while (counter == BUFFER_SIZE); /* do nothing */
buffer[in] = nextProduced;
in = (in + 1) % BUFFER_SIZE;
counter++;
}

Shared Memory Model

Producer-Consumer Problem
PerLab

Consumer process
item nextConsumed;
while (1) {
while (counter == 0);

/* do nothing */

nextConsumed = buffer[out];
out = (out + 1) % BUFFER_SIZE;
counter--;
}

Shared Memory Model

Producer-Consumer Problem
PerLab

The statements
counter++;
counter--;
must be performed atomically.
Atomic operation means an operation that
completes in its entirety without interruption.

Shared Memory Model

Producer-Consumer Problem
PerLab

The statement counter++ 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
Shared Memory Model

10

Producer-Consumer Problem
PerLab

If both the producer and consumer attempt to

update the buffer concurrently, the assembly
language statements may get interleaved.
Interleaving depends upon how the producer and
consumer processes are scheduled.

Shared Memory Model

11

Race Condition
PerLab

Assume counter is initially 5. One interleaving of

statements is:
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)
The value of count may be either 4 or 6, where the correct
result should be 5.
Shared Memory Model

12

Race Condition
PerLab

Race condition
The situation where several processes access and
manipulate shared data concurrently.
The final value of the shared data depends upon which
process finishes last.

To prevent race conditions, concurrent processes

must be synchronized.

Shared Memory Model

13

The Critical-Section Problem

PerLab

n processes 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.

Shared Memory Model

14

Solution to Critical-Section Problem

PerLab

1. Mutual Exclusion
If process Pi is executing in its critical section, then no other
processes can be executing in their critical sections.

2. Progress
If no process is executing in its critical section and there exist
some processes that wish to enter their critical section, then the
selection of the processes that will enter the critical section next
cannot be postponed indefinitely.

3. Bounded Waiting.
A bound must exist on the number of times that other processes
are allowed to enter their critical sections after a process has
made a request to enter its critical section and before that request
is granted.
Assume that each process executes at a nonzero speed
No assumption concerning relative speed of the n processes.
Shared Memory Model

15

General Process Structure

PerLab

General structure of process Pi

do {
entry section
critical section
exit section
reminder section
} while (TRUE)

Shared Memory Model

16

Possible Solutions
PerLab

Software approaches
Hardware solutions
Interrupt disabling
Special machine instructions

Operating System Support

Semaphores

Programming language Support

Monitor

Shared Memory Model

17

Overview
PerLab

The Critical-Section Problem

Software Solutions
Synchronization Hardware
Semaphores
Monitors
Synchronization Examples

Shared Memory Model

18

A Software Solution
PerLab

Boolean lock=FALSE;
Process Pi {
do {
while (lock); // do nothing
lock=TRUE;
critical section
lock=FALSE;
remainder section
} while (TRUE);
}
Does it work?
Shared Memory Model

19

Petersons Solution
PerLab

Two process solution

Assume that the LOAD and STORE instructions
are atomic
The two processes share two variables:
int turn;
Boolean flag[2]

The variable turn indicates whose turn it is to

enter the critical section.
The flag array is used to indicate if a process is
ready to enter the critical section
flag[i] = true implies that process Pi is ready!
Shared Memory Model

20

Algorithm for Process Pi

PerLab

do {
flag[i] = TRUE;
turn = j;
while (flag[j] && turn == j);
critical section
flag[i] = FALSE;
remainder section
} while (TRUE);
}

Shared Memory Model

21

Solution to Critical-section Problem Using Locks

PerLab

do {
acquire lock
critical section
release lock
remainder section
} while (TRUE);

Shared Memory Model

22

Overview
PerLab

The Critical-Section Problem

Software Solutions
Synchronization Hardware
Semaphores
Monitors
Synchronization Examples

Shared Memory Model

23

Synchronization Hardware
PerLab

Many systems provide hardware support for

critical section code
Uniprocessors could disable interrupts
The running process should be pre-empted
during the critical section

Modern machines provide special atomic

hardware instructions

Shared Memory Model

24

Interrupt Disabling
PerLab

do {
disable interrupt;
critical section
enable interrupt;
remainder section
} while (1);

Shared Memory Model

25

Previous Solution
PerLab

do {
while (lock); // do nothing
lock=TRUE;
critical section
lock=FALSE;
remainder section
} while (1);
The solution does not guaranteed the mutual exclusion
because the test and set on lock are not atomic

Shared Memory Model

26

Test-And-Set Instruction
PerLab

Definition:
boolean TestAndSet (boolean *target) {
boolean rv = *target;
*target = TRUE;
return rv;
}

Shared Memory Model

27

Solution using Test-And-Set

PerLab

Boolean lock=FALSE;
do {
while (TestAndSet (&lock )); // do nothing
critical section
lock = FALSE;
remainder section
} while (TRUE);

Shared Memory Model

28

Swap Instruction
PerLab

void Swap (boolean *a, boolean *b) {

boolean temp = *a;
*a = *b;
*b = temp:
}

Shared Memory Model

29

Solution using Swap

PerLab

Shared Boolean variable lock initialized to FALSE

Each process has a local Boolean variable key
do {
key = TRUE;
while ( key == TRUE) Swap (&lock, &key );
critical section
lock = FALSE;
remainder section
} while (TRUE);
This solution guarantees mutual exclusion but not
bounded waiting
Shared Memory Model

30

Bounded-waiting Mutual Exclusion with TestandSet()

PerLab

do {
waiting[i] = TRUE;
key = TRUE;
while (waiting[i] && key) key = TestAndSet(&lock);
waiting[i] = FALSE;
// critical section
j = (i + 1) % n;
while ((j != i) && !waiting[j]) j = (j + 1) % n;
if (j == i) lock = FALSE;
else waiting[j] = FALSE;
// remainder section
} while (TRUE);
Shared Memory Model

31

Overview
PerLab

The Critical-Section Problem

Software Solutions
Synchronization Hardware
Semaphores
Monitors
Synchronization Examples

Shared Memory Model

32

Semaphore
PerLab

Synchronization tool that does not require busy

waiting
Semaphore S integer variable
Can only be accessed via two indivisible (atomic)
operations
wait() and signal()
Originally called P() and V()

Shared Memory Model

33

Semaphore
PerLab

wait (S) {
while (S <= 0);

// do nothing

S--;
}
signal (S) {
S++;
}
wait() and signal() must be atomic
Shared Memory Model

34

Semaphore as General Synchronization Tool

PerLab

Counting semaphore
integer value can range over an unrestricted domain

Binary semaphore
integer value can range only between 0 and 1; can be simpler to
implement
Also known as mutex locks

Can implement a counting semaphore S as a binary

semaphore

Shared Memory Model

35

Semaphore as Mutex Tool

PerLab

Shared data:
semaphore mutex=1;
Process Pi:
do {
wait (mutex);
// Critical Section
signal (mutex);
// Remainder section
} while (TRUE);

Shared Memory Model

36

Semaphore Implementation
PerLab

Must guarantee that no two processes can

execute wait () and signal () on the same
semaphore at the same time
Could have busy waiting (spinlock)
Busy waiting wastes CPU cycles
But avoids context switches
May be useful when the critical section is short and/or
rarely occupied

However applications may spend lots of time in

critical sections and therefore, generally, this is
not a good solution.
Shared Memory Model

37

Semaphore Implementation
PerLab

Define a semaphore as a record

typedef struct {
int value;
struct process *L;
} semaphore;
Assume two simple operations:
block suspends the process that invokes it.
wakeup(P) resumes the execution of a blocked
process P.

Shared Memory Model

38

Implementation
PerLab

Wait (semaphore *S) {

S->value--;
if (S->value < 0) {
add this process to S->list;
block();
}
}
Signal (semaphore *S) {
S->value++;
if (S->value <= 0) {
remove a process P from S->list;
wakeup(P);
}
}
Shared Memory Model

39

Semaphore as a Synchronization Tool

PerLab

Execute B in Pj only after A executed in Pi

Use semaphore flag initialized to 0
Code:

Shared Memory Model

Pi

Pj

wait(flag)

signal(flag)

40

Deadlock and Starvation

PerLab

Deadlock
two or more processes are waiting indefinitely for an event that can
be caused by only one of the waiting processes.

Let S and Q be two semaphores initialized to 1

P0

P1

wait(S);

wait(Q);

wait(Q);

wait(S);

signal(S);

signal(Q);

signal(Q)

signal(S);

Starvation indefinite blocking.

A process may never be removed from the semaphore queue in
which it is suspended.
Shared Memory Model

41

Classical Problems of Synchronization

PerLab

Bounded-Buffer Problem
Readers and Writers Problem
Dining-Philosophers Problem

Shared Memory Model

42

Bounded-Buffer Problem
PerLab

N buffers, each can hold one item

Semaphore mutex initialized to the value 1
Semaphore full initialized to the value 0
Semaphore empty initialized to the value N.

Shared Memory Model

43

Bounded-Buffer Problem
PerLab

Consumer Process

Producer Process

do {
wait(full)
wait(mutex);

<remove item from buffer to

nextc>

signal(mutex);
signal(empty);

<consume item in nextc>

} while (1);

do {

<produce an item in nextp>

wait(empty);
wait(mutex);

<add nextp to buffer>

signal(mutex);
signal(full);
} while (1);
Shared Memory Model

44

Readers-Writers Problem
PerLab

A data set is shared among a number of concurrent

processes
Readers only read the data set; they do not perform any updates
Writers can both read and write

Problem
Allow multiple readers to read at the same time.
Only one single writer can access the shared data at the same time

Variants
No new reader must wait when a writer is waiting for data access
No new reader can start reading when a writer is waiting for data
access

Shared Memory Model

45

Readers-Writers Problem
PerLab

Shared Data
Data set
Integer readcount initialized to 0
Semaphore mutex initialized to 1
Mutual exclusion on readcount

Semaphore wrt initialized to 1

Mutual exclusion on the data set by writers

Shared Memory Model

46

Readers-Writers Problem
PerLab

The structure of a writer process

do {
wait (wrt) ;
// writing is performed
signal (wrt) ;
} while (TRUE);

Shared Memory Model

47

Readers-Writers Problem
PerLab

The structure of a reader process

do {
wait (mutex) ;
readcount ++ ;
if (readcount == 1) wait (wrt) ;
signal (mutex)
// reading is performed
wait (mutex) ;
readcount - - ;
if (readcount == 0) signal (wrt) ;
signal (mutex) ;
} while (TRUE);
Shared Memory Model

48

Dining-Philosophers Problem
PerLab

Shared data
Bowl of rice (data set)
Semaphore chopstick [5] initialized to 1
Shared Memory Model

49

Dining-Philosophers Problem
PerLab

The structure of Philosopher i:

do {
wait (chopstick[i]);
wait (chopStick[ (i + 1) % 5] );
// eat
signal (chopstick[i]);
signal (chopstick[ (i + 1) % 5] );
// think
} while (TRUE);
Shared Memory Model

50

Dining-Philosophers Problem
PerLab

Deadlock
A deadlock occurs if all philosophers start eating
simultaneously

Possible solutions to avoid deadlocks

Only 4 philosophers can sit around the table
A philosopher can take his/her chopsticks only if they both are
free
An odd philosopher takes the chopstick on its left first, and
then the one on its right; an even philosopher takes the
opposite approach.

Starvation
Any solution must avoid that a philosopher may starve
Shared Memory Model

51

Problems with Semaphores

PerLab

Incorrect use of semaphore operations:

signal (mutex) . wait (mutex)
wait (mutex) wait (mutex)
Omitting of wait (mutex) or signal (mutex) (or
both)

Shared Memory Model

52

Overview
PerLab

The Critical-Section Problem

Software Solutions
Synchronization Hardware
Semaphores
Monitors
Synchronization Examples

Shared Memory Model

53

Monitors
PerLab

A high-level abstraction that provides a convenient and

effective mechanism for process synchronization
Only one process may be active within the monitor at a
time
monitor monitor-name {
// shared variable declarations
procedure P1 () { . }

procedure Pn () {}
Initialization code ( .) {

}
}
Shared Memory Model

54

Schematic view of a Monitor

PerLab

Shared Memory Model

55

Monitor with Condition Variables

PerLab

Shared Memory Model

56

Condition Variables
PerLab

condition x, y;
Two operations on a condition variable:
x.wait () a process that invokes the operation is (always)
suspended.
x.signal () resumes one of processes (if any) that
invoked x.wait ().

Variants (P executes x.signal() and Q was blocked on x)

Signal and wait: P waits for Q leaving the monitor or blocking
on another condition variable before proceedings on
Signal and proceed: Q waits for P leaving the monitor or
blocking on another condition variable before proceedings on
Signal and Leave: P executes signal and leaves the monitor
(Concurrent Pascal)
Shared Memory Model

57

Solution to Dining Philosophers

PerLab

Based on monitors
The solution assumes that
A philosopher can take his/her chopsticks only when
are both free

The proposed solution is deadlock-free

Shared Memory Model

58

Solution to Dining Philosophers

PerLab

monitor DP {
enum { THINKING; HUNGRY, EATING) state [5] ;
condition self [5];
void pickup (int i) {
state[i] = HUNGRY;
test(i);
if (state[i] != EATING) self [i].wait;
}
void putdown (int i) {
state[i] = THINKING;
// test left and right neighbors
test((i + 4) % 5);
test((i + 1) % 5);
}
Shared Memory Model

59

Solution to Dining Philosophers

PerLab

void test (int i) {

if ( (state[(i + 4) % 5] != EATING) &&
(state[i] == HUNGRY) &&
(state[(i + 1) % 5] != EATING) ) {
state[i] = EATING ;
self[i].signal () ;
}
}
initialization_code() {
for (int i = 0; i < 5; i++)
state[i] = THINKING;
}
}
Shared Memory Model

60

Solution to Dining Philosophers

PerLab

Each philosopher invokes the operations

pickup() and putdown() in the following
sequence:

While (1) {
DP.pickup (i);
Eat;
DP.putdown (i);
Think;
}
Shared Memory Model

61

Overview
PerLab

The Critical-Section Problem

Software Solutions
Synchronization Hardware
Semaphores
Monitors
Synchronization Examples

Shared Memory Model

62

Synchronization Examples
PerLab

Solaris
Windows XP
Linux
Pthreads

Shared Memory Model

63

Solaris Synchronization
PerLab

Implements a variety of mechanisms to support

multitasking, multithreading (including real-time
threads), and multiprocessing
Adaptive mutexes for efficiency when protecting
data from short code segments
Uses semaphores, condition variables and
readers-writers locks when longer sections of
code need access to data

Shared Memory Model

64

Windows XP Synchronization
PerLab

Uses interrupt masks to protect access to global

resources from kernel threads on uniprocessor
systems
Uses spinlocks on multiprocessor systems
For out-of-kernel synch provides dispatcher
objects
may act as either mutexes and semaphores

Dispatcher objects may also provide events

An event acts much like a condition variable

Shared Memory Model

65

Linux Synchronization
PerLab

Linux:
Prior Version 2.6, non-preemptive kernel
A task executed in system mode cannot be interrupted, even by a
higher-priority thread

Version 2.6 and later, fully preemptive

Linux provides:
semaphores
spin locks

Linux kernel
Multi-processor
Enable/disable spinlocks (active only for short times)

Single-processor
Disable/Enable preemption

Shared Memory Model

66

Pthreads Synchronization
PerLab

Pthreads API is OS-independent

It provides:
mutex locks
condition variables

Non-portable extensions include:

read-write locks
spin locks

Shared Memory Model

67

Questions?
PerLab

Shared Memory Model

68