Module 2B: Process

Synchronization

Operating System Concepts – 8th Edition Silberschatz, Galvin and Gagne ©2009

Outline
Introduction to Process – Scheduling – Operations-Interprocess Communication. Synchronization: Critical
Section-Hardware- Mutex- Semaphore –Monitors. Threads: Multithreading Models- Thread Library- Issues

● Background
● The Critical-Section Problem
● Peterson’s Solution
● Synchronization Hardware
● Semaphores
● Classic Problems of Synchronization
● Monitors

Operating System Concepts – 8th Edition 2 Silberschatz, Galvin and Gagne ©2009
 Objectives
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

To introduce the concept of an atomic transaction and describe mechanisms to ensure atomicity
 Operating System Concepts – 8th Edition 3 Silberschatz, Galvin and Gagne ©2009

Background
● Concurrent access to shared data may result in data inconsistency

● Maintaining data consistency requires mechanisms to ensure the orderly execution of cooperating
processes

● Suppose that we wanted to provide a solution to the consumer-producer problem that fills all the buffers.
We can do so by having an integer count that keeps track of the number of full buffers. Initially, count is
set to 0. It is incremented by the producer after it produces a new buffer and is decremented by the
consumer after it consumes a buffer.
 Operating System Concepts – 8th Edition 4 Silberschatz, Galvin and Gagne ©2009

Producer
while (true) {

/* produce an item and put in nextProduced */

while (counter == BUFFER_SIZE)
; // do nothing
buffer [in] = nextProduced;
in = (in + 1) % BUFFER_SIZE;
 counter++;
}

Operating System Concepts – 8th Edition 5 Silberschatz, Galvin and Gagne ©2009

Consumer

while (true) {

while (counter == 0)
; // do nothing
nextConsumed = buffer[out];
out = (out + 1) % BUFFER_SIZE;
 counter--;

/* consume the item in nextConsumed */

}

Operating System Concepts – 8th Edition 6 Silberschatz, Galvin and Gagne ©2009

Race Condition
Race Condition is a situation that occurs when two or more threads or processes access a
shared resource, such as a file or a variable, at the same time.
Ex
counter++ could be implemented as
register1 = counter
register1 = register1 + 1
counter = register1

counter-- could be implemented as

register2 = counter
register2 = register2 - 1
count = register2

Consider this execution interleaving with “count = 5” initially:

S0: producer execute register1 = counter {register1 = 5}
S1: producer execute register1 = register1 + 1 {register1 = 6}
S2: consumer execute register2 = counter {register2 = 5}
S3: consumer execute register2 = register2 - 1 {register2 = 4}
S4: producer execute counter = register1 {count = 6 }
S5: consumer execute counter = register2 {count = 4}

Operating System Concepts – 8th Edition 7 Silberschatz, Galvin and Gagne ©2009

Cont…
The following race condition occurs:
App A reads the current balance, which is ₹1000
App A adds ₹200 to ₹1000 and gets ₹1200 as the final balance
Meanwhile, app B fetches the current balance, which is still ₹1000, as app A has not executed step 3
App B adds ₹500 to ₹1000 and gets ₹1500 as the final balance
App B updates the account balance to ₹1500
App A updates the account balance to ₹1200
Thus the final balance is ₹1200 instead of ₹1700

Operating System Concepts – 8th Edition Silberschatz, Galvin and Gagne ©2009

Critical Section Problem

Consider system of n processes {p0, p1, … pn-1}
Each process has critical section segment of code
Process may be changing common variables, updating table, writing file, etc
 When one process in critical section, no other may be in its critical section
Critical section problem is to design protocol to solve this
Each process must ask permission to enter critical section in entry section, may follow critical section with exit
section, then remainder section
Especially challenging with preemptive kernels

Operating System Concepts – 8th Edition 9 Silberschatz, Galvin and Gagne ©2009

Critical Section
General structure of process pi is
 Operating System Concepts – 8th Edition 1 Silberschatz, Galvin and Gagne ©2009

Solution to Critical-Section Problem

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. This should not lead to the problem of Starvation.
Assume that each process executes at a nonzero speed
No assumption concerning relative speed of the n processes
4. No assumption related to Hardware and Speed- Execute solution must be universal ie easily flexible and
portable.

Operating System Concepts – 8th Edition 11 Silberschatz, Galvin and Gagne ©2009

Solution 1 to CS problem-Lock variable

Initially lock=0
Entry Section →
1. While (lock! = 0); #
2. Lock = 1;
3. Critical Section
Exit Section →
4. Lock =0;

Every Synchronization mechanism is judged on the basis of four conditions.

1. Mutual Exclusion- Not Satisfied as instruction 1 and 2 can have preemption in between
2. Progress
3. Bounded Waiting
4. Portability

Operating System Concepts – 8th Edition 12 Silberschatz, Galvin and Gagne ©2009

Solution 2 to CS problem-Test and set Test and

Set Lock (TSL) is a synchronization mechanism.
It uses a test and set instruction to provide the synchronization among the processes executing
concurrently. Initially lock=False
Entry Section →
1. While (test_and_set(&lock));#Instruction to avoid preemption
2. Critical Section
Exit Section →
3. Lock = False;
boolean test_and_set(boolean *target)
{
boolean r = *target;
*target=True;
r;
}
return

Every Synchronization mechanism is judged on the basis of four conditions.

1. Mutual Exclusion- Satisfied
2. Progress- Satisfied
3. Bounded Waiting
4. Portability

Operating System Concepts – 8th Edition 13 Silberschatz, Galvin and Gagne ©2009
 Cont…
● It is an instruction that returns the old value of a memory location and sets the memory location
value to 1 as a single atomic operation.
● If one process is currently executing a test-and-set, no other process is allowed to begin another
test-and-set until the first process test-and-set is finished.
Characteristics of this synchronization mechanism are-
● It ensures mutual exclusion.
● It is deadlock free, progress is achieved
● It does not guarantee bounded waiting and may cause starvation.
● It is not architectural neutral since it requires the operating system to support test-and-set instruction.
 Operating System Concepts – 8th Edition Silberschatz, Galvin and Gagne ©2009

Peterson’s Algorithm 1- Using Turn Variable

● Turn Variable/Strict Alteration/Two-process solution
○ Turn variable is a synchronization mechanism that provides synchronization among two
processes.
○ It uses a turn variable to provide the synchronization.
 Operating System Concepts – 8th Edition Silberschatz, Galvin and Gagne ©2009

Cont..
● Initially, turn value is set to 0.
○ Turn value = 0 means it is the turn of process P0 to enter the critical section.
○ Turn value = 1 means it is the turn of process P1 to enter the critical section.

The characteristics of this synchronization mechanism are-

○ It ensures mutual exclusion.
○ It does not guarantee progress since it follows strict alternation approach.
○ It ensures bounded waiting since processes are executed turn wise one by one and each process is
guaranteed to get a chance.
○ It ensures processes does not starve for the CPU.
○ It is architectural neutral since it does not require any support from the operating system
* In strict alternation approach,
○ Processes have to compulsorily enter the critical section alternately whether they want it or not. ○ This
is because if one process does not enter the critical section, then other process will never get a chance to
execute again.
 Operating System Concepts – 8th Edition Silberschatz, Galvin and Gagne ©2009

Peterson’s Algorithm 2- Using Flag array

var flag :array[0…..1] of boolean;
Elements of array are initialized to False
flag[i]=True indicates Process i is ready to enter critical section
do
{ flag[i]= True;
while (Flag[j]) do no op;
// Critical section
flag[i]= False;
Remainder section;
} while(True);
 Operating System Concepts – 8th Edition 17 Silberschatz, Galvin and Gagne ©2009

Peterson’s Solution 2- Using Flag array

Every Synchronization mechanism is judged on the basis of four conditions.
1. Mutual Exclusion- Satisfied
2. Progress- Not Satisfied

P0 sets Flag[0]=True

P1 sets Flag[1]=True at same time

Then both will loop in their respective while loop together

3. Bounded Waiting
4. Portability

● Algo is dependent on exact timing of two processes

Operating System Concepts – 8th Edition 18 Silberschatz, Galvin and Gagne ©2009

Peterson’s or Deker’s Solution Two

process solution- Combined Algorithm 1 and 2
Assume that the LOAD and STORE instructions are atomic; that is, cannot be interrupted

The two processes share two variables:

int turn;
Boolean flag[2]
Initially flag[0]=flag[1]= False

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!

Operating System Concepts – 8th Edition 19 Silberschatz, Galvin and Gagne ©2009

Algorithm for Process Pi

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

1. Mutual exclusion is preserved

2. Progress requirement is satisfied
3. Bounded-waiting requirement is met

Operating System Concepts – 8th Edition 20 Silberschatz, Galvin and Gagne ©2009

Multi-process Solution-Bakery
Algorithm ● Algorithm to solve Critical Section for Multi-processes or N processes
● The Bakery algorithm is one of the simplest known solutions to the mutual exclusion problem for the general case
of N process.
● The algorithm preserves the first come first serve property.

How it works?

● In the Bakery Algorithm, each process is assigned a number (a ticket) in a lexicographical order. Before entering the
critical section, a process receives a ticket number, and the process with the smallest ticket number enters the
critical section. If two processes receive the same ticket number, the process with the lower process ID is given
priority.
○ Before entering its critical section, the process receives a number. Holder of the smallest number enters the
critical section.
○ If processes Pi and Pj receive the same number, then
■ if i < j
■ Pi is served first;
■ else
■ Pj is served first.

Operating System Concepts – 8th Edition Silberschatz, Galvin and Gagne ©2009

Cont…
Condition for lexicographical order (ticket #, process id #)

-Firstly the ticket number is compared. If same then the process ID is compared next
– (a, b) < (c, d) if a < c or if a = c and b < d
 – max(a [0], . . ., a [n-1]) is a number, k, such that k >= a[i] for i = 0, . . ., n - 1

Shared data associated with a process–

● choosing is an array [0..n – 1] of boolean values;

● number is an array [0..n – 1] of integer values.
● Both are initialized to False & Zero respectively.

Operating System Concepts – 8th Edition Silberschatz, Galvin and Gagne ©2009

Psuedocode
do {
choosing[i] := True;

number[i] := max(number[0], number[1], ..., number[n - 1])+1;

choosing[i] := False;

for j := 0 to n - 1

begin

while choosing[j] do no-op;

while number[j] != 0 and (number[j], j) < (number[i], i) do no-op;

end;

// Critical section

number[i] := 0;

remainder section

} while(True);

Operating System Concepts – 8th Edition Silberschatz, Galvin and Gagne ©2009

Cont..
Mutual Exclusion- Satisfied
If P1 is in CS and P2 trying to enter, on the second while if condition become True, it loops
until P1 leaves CS
Progress is also there as Process enter in FCFS
Bounded waiting is there as process before leaving sets number[i]=0 and
choosing [i]=False
No hardware dependency

Operating System Concepts – 8th Edition Silberschatz, Galvin and Gagne ©2009

Semaphore
● Synchronization tool used to avoid race condition in concurrent processes
● It that does not require busy waiting

● Deals with n processes Critical Section problem where they share a

common variable semaphore(mutex)
● Semaphore S – integer variable - used to achieve Mutual Exclusion in
order to achieve synchronization among n cooperating processes

Operating System Concepts – 8th Edition 25 Silberschatz, Galvin and Gagne ©2009
 Semaphore
● Two standard operations modify S: wait() and signal()
○ Originally called P() and V()
○ Also known as Down() and Up()
● Less complicated
● Semaphore S – integer variable initialized to 1 ● Can only be
accessed via two indivisible (atomic) operations
wait (S) {
while S <= 0
; // no-op
S--;
}
signal (S) {
S++;

}
 Operating System Concepts – 8th Edition 26 Silberschatz, Galvin and Gagne ©2009

Semaphore as
General Synchronization Tool

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
Provides mutual exclusion
Semaphore mutex; // initialized to 1
do {
wait (mutex);
// Critical Section
signal (mutex);
// remainder section
} while (TRUE);
 Operating System Concepts – 8th Edition 27 Silberschatz, Galvin and Gagne ©2009

Semaphore Implementation
● Must guarantee that no two processes can execute wait () and signal () on the same
semaphore at the same time
● Thus, implementation becomes the critical section problem where the wait and signal code
are placed in the critical section
● Could now have busy waiting in critical section implementation
○ Busy waiting is defined as the process where the process or task continuously
the processor and waits for the condition to be satisfied. This leads to wastage
of CPU cycles that some other process will be able to use productively
○ But implementation code is short
○ Little busy waiting if critical section rarely occupied
● Note that applications may spend lots of time in critical sections and therefore this is not a
 good solution

Operating System Concepts – 8th Edition 28 Silberschatz, Galvin and Gagne ©2009

Semaphore Implementation
with no Busy waiting

● Semaphore called as Spinlock

● With each semaphore there is an associated waiting queue
● Each entry in a waiting queue has two data items: ○ value
(of type integer)
○ pointer to next record in the list
● Two operations:
○ block – place the process invoking the operation on the
 appropriate waiting queue
○ wakeup – remove one of processes in the waiting queue and
place it in the ready queue

Operating System Concepts – 8th Edition 29 Silberschatz, Galvin and Gagne ©2009

Semaphore Implementation with

no Busy waiting (Cont.)

Implementation of wait:
wait(semaphore *S) {
S->value--;
if (S->value < 0) {
add this process to S->list; // Add process to suspended/block list
block();
}
}
Implementation of signal:

signal(semaphore *S) {
 S->value++;
if (S->value <= 0) // Indicates some process in suspended list
{
remove a process P from S->list;
wakeup(P);
}
}

Operating System Concepts – 8th Edition 30 Silberschatz, Galvin and Gagne ©2009

Deadlock and Starvation

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 P 1
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
Priority Inversion – Scheduling problem when lower-priority process holds a lock needed by higher-priority
process
Solved via priority-inheritance protocol

Operating System Concepts – 8th Edition 31 Silberschatz, Galvin and Gagne ©2009

Classical Problems of
Synchronization Classical problems used to test newly-proposed synchronization

schemes

● Bounded-Buffer Problem

● Readers and Writers Problem

● Dining-Philosophers Problem

Operating System Concepts – 8th Edition 32 Silberschatz, Galvin and Gagne ©2009

Bounded-Buffer Problem
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
 wait(S){
while(S<=0); // busy waiting
S--;
}

signal(S){
S++;
}

Operating System Concepts – 8th Edition 33 Silberschatz, Galvin and Gagne ©2009

Bounded Buffer Problem (Cont.) The

structure of the producer process
do {
// produce an item in nextp
wait (empty);
wait (mutex);

// add the item to the buffer

signal (mutex);
signal (full);
} while (TRUE);

Operating System Concepts – 8th Edition 34 Silberschatz, Galvin and Gagne ©2009

Bounded Buffer Problem (Cont.) The

structure of the consumer process
do {
wait (full);
wait (mutex);

// remove an item from buffer to nextc

signal (mutex);
signal (empty);

// consume the item in nextc

} while (TRUE);

Operating System Concepts – 8th Edition 35 Silberschatz, Galvin and Gagne ©2009

Readers-Writers Problem
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

Several variations of how readers and writers are treated – all involve priorities

Shared Data
Data set
Semaphore mutex initialized to 1
Semaphore wrt initialized to 1
Integer readcount initialized to 0

Operating System Concepts – 8th Edition 36 Silberschatz, Galvin and Gagne ©2009

Readers-Writers Problem (Cont.)

The structure of a writer process
do {
wait (wrt) ;

// writing is performed

signal (wrt) ;
} while (TRUE);

Operating System Concepts – 8th Edition 37 Silberschatz, Galvin and Gagne ©2009

Readers-Writers Problem (Cont.)

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);

Operating System Concepts – 8th Edition 38 Silberschatz, Galvin and Gagne ©2009
 Readers-Writers Problem
Variations First variation – no reader kept waiting unless writer has permission to use shared
object
Second variation – once writer is ready, it performs write asap

Both may have starvation leading to even more variations

Problem is solved on some systems by kernel providing reader-writer locks

 Operating System Concepts – 8th Edition 39 Silberschatz, Galvin and Gagne ©2009

Dining-Philosophers Problem
Philosophers spend their lives thinking and eating
Don’t interact with their neighbors, occasionally try to pick up 2 chopsticks (one at a time) to eat from bowl
Need both to eat, then release both when done
In the case of 5 philosophers
Shared data
Bowl of rice (data set)
Semaphore chopstick [5] initialized to 1

Operating System Concepts – 8th Edition 40 Silberschatz, Galvin and Gagne ©2009

Dining-Philosophers Problem Algorithm

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);

What is the problem with this algorithm?

Operating System Concepts – 8th Edition 41 Silberschatz, Galvin and Gagne ©2009

Problems with Semaphores

 -Incorrect use of semaphore operations:

signal (mutex) …. wait (mutex)

wait (mutex) … wait (mutex)

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

-Deadlock and starvation

Operating System Concepts – 8th Edition 42 Silberschatz, Galvin and Gagne ©2009
 Solutions to avoid deadlock
- Allow N-1 persons to sit simultaneously, so one Process i can get access to both
chopsticks and start eating. After eating, releases fork so Process j can start eating -
Allow Philosopher to pick up chopsticks if both are available
- Use a asymmetric solution where Odd Philosopher picks up left chopstick first ,
then Right and even Philosopher did vice versa
 Operating System Concepts – 8th Edition Silberschatz, Galvin and Gagne ©2009

Monitors
● A high-level abstraction that provides a convenient and effective mechanism
for process synchronization
● Abstract data type, internal variables only accessible by code within the procedure
● Only one process may be active within the monitor at a time ● But not
powerful enough to model some synchronization schemes

monitor monitor-name
{
// shared variable declarations
procedure P1 (…) { …. }// Procedures that can be performed on shared
variables

procedure Pn (…) {……}

Initialization code (…) { … }

}
 }
Operating System Concepts – 8th Edition 44 Silberschatz, Galvin and Gagne ©2009

Schematic view of a Monitor

 Operating System

Concepts – 8th Edition 45 Silberschatz, Galvin and Gagne ©2009

Condition Variables/constructs condition

 x, y; //required to achieve process synchronization
Two operations invoked on a condition variable:
x.wait () – a process that invokes the operation is suspended until x.signal ()
x.signal () – resumes one of processes (if any) that invoked x.wait ().
If no x.wait () on the variable, then it has no effect on the variable

Video link for Monitor

https://www.youtube.com/watch?v=ufdQ0GR855M

Video link for Dining Philosopher using Monitor

https://www.youtube.com/watch?v=K52NiClfvyE

Operating System Concepts – 8th Edition 46 Silberschatz, Galvin and Gagne ©2009

Monitor with Condition

Variables-Schematic View
Operating System Concepts – 8th Edition 47 Silberschatz, Galvin and Gagne ©2009
 Condition Variables Choices
If process P invokes x.signal (), with Q in x.wait () state, what should happen next?
If Q is resumed, then P must wait

Options include
Signal and wait – P waits until Q leaves monitor or waits for another condition
Signal and continue – Q waits until P leaves the monitor or waits for another condition

Both have pros and cons – language implementer can decide

Monitors implemented in Concurrent Pascal compromise
P executing signal immediately leaves the monitor, Q is resumed
Implemented in other languages including Mesa, C#, Java
 Operating System Concepts – 8th Edition 48 Silberschatz, Galvin and Gagne ©2009

Solution to Dining Philosophers

monitor DiningPhilosophers
{
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);
}
 Operating System Concepts – 8th Edition 49 Silberschatz, Galvin and Gagne ©2009

Solution to Dining Philosophers (Cont.)

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;
}
}

Operating System Concepts – 8th Edition 50 Silberschatz, Galvin and Gagne ©2009

Solution to Dining Philosophers (Cont.)

Each philosopher i invokes the operations pickup() and putdown() in the following sequence:

DiningPhilosophers.pickup (i);

EAT

DiningPhilosophers.putdown (i);

No deadlock, but starvation is possible

 Operating System Concepts – 8th Edition 51 Silberschatz, Galvin and Gagne ©2009

Monitor Implementation Using Semaphores

Variables
semaphore mutex; // (initially = 1)
semaphore next; // (initially = 0)
int next_count = 0;

Each procedure F will be replaced by

wait(mutex);
…
body of F;
 …
if (next_count > 0)
signal(next)
else
signal(mutex);

Mutual exclusion within a monitor is ensured

Operating System Concepts – 8th Edition 52 Silberschatz, Galvin and Gagne ©2009

Monitor Implementation – Condition

Variables For each condition variable x, we have:
semaphore x_sem; // (initially = 0)
int x_count = 0;

The operation x.wait can be implemented as:

x-count++;
if (next_count > 0)
 signal(next);
else
signal(mutex);
wait(x_sem);
x-count--;

Operating System Concepts – 8th Edition 53 Silberschatz, Galvin and Gagne ©2009

Monitor Implementation (Cont.) The

operation x.signal can be implemented as:
if (x-count > 0) {
next_count++;
signal(x_sem);
wait(next);
next_count--;
}
 Operating System Concepts – 8th Edition 54 Silberschatz, Galvin and Gagne ©2009

Resuming Processes within a Monitor

If several processes queued on condition x, and x.signal() executed, which should be resumed?
FCFS frequently not adequate

conditional-wait construct of the form x.wait(c)

Where c is priority number
Process with lowest number (highest priority) is scheduled next
 Operating System Concepts – 8th Edition 55 Silberschatz, Galvin and Gagne ©2009

A Monitor to Allocate Single Resource

monitor ResourceAllocator
{
boolean busy;
condition x;
void acquire(int time) {
if (busy)
 x.wait(time);
busy = TRUE;
}
void release() {
busy = FALSE;
x.signal();
}
initialization code() {
busy = FALSE;
}
}

Operating System Concepts – 8th Edition 56 Silberschatz, Galvin and Gagne ©2009

Synchronization Examples Solaris

Windows XP

Linux

Pthreads
 Operating System Concepts – 8th Edition 57 Silberschatz, Galvin and Gagne ©2009

Solaris Synchronization Implements a variety of locks to support

multitasking, multithreading (including real-time threads), and multiprocessing

Uses adaptive mutexes for efficiency when protecting data from short code segments
Starts as a standard semaphore spin-lock
If lock held, and by a thread running on another CPU, spins
If lock held by non-run-state thread, block and sleep waiting for signal of lock being released

Uses condition variables

Uses readers-writers locks when longer sections of code need access to data

Uses turnstiles to order the list of threads waiting to acquire either an adaptive mutex or reader-writer lock
Turnstiles are per-lock-holding-thread, not per-object

Priority-inheritance per-turnstile gives the running thread the highest of the priorities of the threads in its turnstile

Operating System Concepts – 8th Edition 58 Silberschatz, Galvin and Gagne ©2009

Windows XP Synchronization Uses

interrupt masks to protect access to global resources on uniprocessor systems
Uses spinlocks on multiprocessor systems
Spinlocking-thread will never be preempted

Also provides dispatcher objects user-land which may act mutexes, semaphores, events, and timers

Events
 An event acts much like a condition variable
Timers notify one or more thread when time expired
Dispatcher objects either signaled-state (object available) or non-signaled state (thread will block)

Operating System Concepts – 8th Edition 59 Silberschatz, Galvin and Gagne ©2009

Linux Synchronization
Linux:
Prior to kernel Version 2.6, disables interrupts to implement short critical sections
Version 2.6 and later, fully preemptive

Linux provides:
semaphores
spinlocks
 reader-writer versions of both

On single-cpu system, spinlocks replaced by enabling and disabling kernel preemption

Operating System Concepts – 8th Edition 60 Silberschatz, Galvin and Gagne ©2009

Pthreads Synchronization
Pthreads API is OS-independent

It provides:
mutex locks
condition variables
Non-portable extensions include:
read-write locks
spinlocks

Operating System Concepts – 8th Edition 61 Silberschatz, Galvin and Gagne ©2009

End of Module 2B
Operating System Concepts – 8th Edition Silberschatz, Galvin and Gagne ©2009