‫الجامعة السعودية االلكترونية‬

‫الجامعة السعودية االلكترونية‬

‫‪26/12/2021‬‬
College of Computing and Informatics
OPERATING SYSTEMS
Operating Systems
Module 4

Chapter 6: Synchronization Tools

CONTENTS

 The Critical-Section Problem

 Peterson’s Solution

 Hardware Support for Synchronization

 Mutex Locks

 Semaphores
WEEKLY LEARNING OUTCOMES

 Describe the critical-section problem and illustrate a race condition

 Illustrate hardware solutions to the critical-section problem using

memory barriers, compare-and-swap operations, and atomic variables

 Demonstrate how Mutex locks and semaphores can be used to solve

the critical section problem

 Explain the bounded-buffer, readers-writers and dining-philosophers

synchronization problem.
 INTRODUCTION
Processes can execute concurrently
May be interrupted at any time, partially completing execution
Concurrent access to shared data may result in data inconsistency
Maintaining data consistency requires mechanisms to ensure the orderly
execution of cooperating processes
We illustrated in chapter 4 the problem when we considered the Bounded Buffer
problem with use of a counter that is updated concurrently by the producer and
consumer,. Which lead to race condition.
 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
CRITICAL SECTION
General structure of process Pi
 REQUIREMENT FOR CRITICAL SECTION
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
process 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
4. Assume that each process executes at a nonzero speed
5. No assumption concerning relative speed of the n processes
 RACE CONDITION
Processes P0 and P1 are creating child processes using the fork() system call
Race condition on kernel variable next_available_pid which represents the next available
process identifier (pid)
Unless there is a mechanism to prevent P0 and P1 from accessing the variable
next_available_pid the same pid could be assigned to two different processes!
 PETERSON’S SOLUTION
Two process solution
Assume that the load and store machine-language instructions are atomic;
that is, cannot be interrupted
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!
ALGORITHM FOR PROCESS
while (true){

flag[i] = true;
turn = j;
while (flag[j] && turn = = j)
;

/* critical section */

flag[i] = false;

/* remainder section */

}
CORRECTNESS OF PETERSON’S SOLUTION
Provable that the three CS requirement are met:
1. Mutual exclusion is preserved
Pi enters CS only if:
either flag[j] = false or turn = i
2. Progress requirement is satisfied
3. Bounded-waiting requirement is met
 PETERSON’S SOLUTION
Although useful for demonstrating an algorithm, Peterson’s Solution is not
guaranteed to work on modern architectures.
To improve performance, processors and/or compilers may reorder operations
that have no dependencies
Understanding why it will not work is useful for better understanding race
conditions.
For single-threaded this is ok as the result will always be the same.
For multithreaded the reordering may produce inconsistent or unexpected
results!
 SYNCHRONIZATION HARDWARE
Many systems provide hardware support for implementing the critical section
code.
Uniprocessors – could disable interrupts
Currently running code would execute without preemption
Generally too inefficient on multiprocessor systems
Operating systems using this not broadly scalable
We will look at three forms of hardware support:

1. Hardware instructions

2. Atomic variables
 HARDWARE INSTRUCTIONS
Special hardware instructions that allow us to either test-and-modify the content
of a word, or to swap the contents of two words atomically (uninterruptedly.)
Test-and-Set instruction
Compare-and-Swap instruction
The test_and_set Instruction
Definition
boolean test_and_set (boolean *target)
{
boolean rv = *target;
*target = true;
return rv:
}
Properties
Executed atomically
Returns the original value of passed parameter
Set the new value of passed parameter to true
Solution Using test_and_set()
Shared boolean variable lock, initialized to false
Solution:
do {
while (test_and_set(&lock))
; /* do nothing */

/* critical section */

lock = false;
/* remainder section */
} while (true);

Does it solve the critical-section problem?

 Atomic Variables
Typically, instructions such as compare-and-swap are used as building blocks for
other synchronization tools.
One tool is an atomic variable that provides atomic (uninterruptible) updates on
basic data types such as integers and booleans.
For example:
Let sequence be an atomic variable
Let increment() be operation on the atomic variable sequence
The Command:
increment(&sequence);
ensures sequence is incremented without interruption:
 MUTEX LOCK
Previous solutions are complicated and generally inaccessible to application programmers
OS designers build software tools to solve critical section problem
Simplest is mutex lock
Boolean variable indicating if lock is available or not
Protect a critical section by
First acquire() a lock
Then release() the lock
Calls to acquire() and release() must be atomic
Usually implemented via hardware atomic instructions such as compare-and-swap.
But this solution requires busy waiting
This lock therefore called a spinlock
SOLUTION USING MUTEX LOCK
while (true) {
acquire lock

critical section

release lock

remainder section
}
 SEMAPHORE
Synchronization tool that provides more sophisticated ways (than Mutex locks) for processes to synchronize their activities.
Semaphore S – integer variable
Can only be accessed via two indivisible (atomic) operations
wait() and signal()
Originally called P() and V()
Definition of the wait() operation
wait(S) {
while (S <= 0)
; // busy wait
S--;
}
Definition of the signal() operation
signal(S) {
S++;
}
 SEMAPHORE
Counting semaphore – integer value can range over an unrestricted domain
Binary semaphore – integer value can range only between 0 and 1
Same as a mutex lock
Can implement a counting semaphore S as a binary semaphore
With semaphores we can solve various synchronization problems
 SEMAPHORE EXAMPLE
Solution to the CS Problem
Create a semaphore “mutex” initialized to 1
wait(mutex);
CS
signal(mutex);
Consider P1 and P2 that with two statements S1 and S2 and the requirement that S1 to happen
before S2
Create a semaphore “synch” initialized to 0
P1:
S1;
signal(synch);
P2:
wait(synch);
S2;
 SEMAPHORE IMPLEMENTATION
Must guarantee that no two processes can execute the wait() and signal() on the
same semaphore at the same time
Thus, the 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
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
SEMAPHORE IMPLEMENTATION WITH NO BUSY WAIT
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
 Main Reference
Chapter 6: Synchronization Tools
(Operating System Concepts by Silberschatz, Abraham, et al. 10th ed.,
ISBN: 978-1-119-32091-3, 2018)

Additional References
Chapter 2.3
Chapter 2.5
(Modern Operating Systems by Andrew S. Tanenbaum and Herbert Bos. 4th
ed., ISBN-10: 0-13-359162-X, ISBN-13: 978-0-13-359162-0, 2015)

sentation is mainly dependent on the textbook: Operating System Concepts by Silberschatz, Abrah
Thank You