Chapter 6: Synchronization

Tools

Operating System Concepts – 10th Edition Silberschatz, Galvin and Gagne ©2018
 Outline
▪ Background
▪ The Critical-Section Problem
▪ Hardware Support for Synchronization
▪ Mutex Locks
▪ Semaphores
▪ Monitors
▪ Liveness

Operating System Concepts – 10th Edition 6.2 Silberschatz, Galvin and Gagne ©2018
 Objectives
▪ Describe the critical-section problem and illustrate a
race condition
▪ Illustrate hardware solutions to the critical-section
problem
▪ Demonstrate how mutex locks, semaphores,
monitors, and condition variables can be used to
solve the critical section problem

Operating System Concepts – 10th Edition 6.3 Silberschatz, Galvin and Gagne ©2018
 Background
▪ 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

Operating System Concepts – 10th Edition 6.4 Silberschatz, Galvin and Gagne ©2018
 Synchronous vs. Asynchronous
▪ Synchronous = tasks happen simultaneously "at the same time " on a shared resource; thus, we
need a mechanism to control their actions. On the other hand, "Synchronous" means "using the
same clock," so when two instructions are synchronous, they use the same clock and must
happen one after the other
▪ Asynchronous = doesn't happen at the same time. On the other hand, "Asynchronous" means
"not using the same clock," so the instructions are not concerned with being in step with each
other
▪ Suppose we have one CPU with one core. In that case, the Operating system simulates the
execution of two tasks simultaneously "at the same time" by providing a time slice for each one at
a given specific time, but if we have one CPU with two cores, things CAN happen at the same
time
▪ The operating system is responsible for managing the synchronization between tasks
▪ Also, # of physical cores is < # of processes, thus we need synchronization mechanism
▪ Processes Synchronization or Synchronization is the way by which processes that share the same memory space
are managed in an operating system. It helps maintain the consistency of data by using variables or hardware so
that only one process can make changes to the shared memory at a time

Operating System Concepts – 10th Edition 6.5 Silberschatz, Galvin and Gagne ©2018
 Race Condition
▪ Race condition happened when two operations at the same time are competing
for which one should be executed first
▪ 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!

Operating System Concepts – 10th Edition 6.6 Silberschatz, Galvin and Gagne ©2018
 Critical Section Problem

▪ The critical section problem is to make sure that only one process should
be in a critical section at a time.
▪ When a process is in the critical section, no other processes are allowed
to enter the critical section. This solves the race condition (Race condition
among the processes will never arise).

▪ 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

Operating System Concepts – 10th Edition 6.7 Silberschatz, Galvin and Gagne ©2018
 Critical Section

▪ General structure of process Pi

Operating System Concepts – 10th Edition 6.8 Silberschatz, Galvin and Gagne ©2018
 Critical-Section Problem (Cont.)
Requirements for 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 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. The purpose of this condition is to make sure that every process
gets the chance to actually enter its critical section so that no process
starves forever.
• Assume that each process executes at a nonzero speed
• No assumption concerning relative speed of the n processes

Operating System Concepts – 10th Edition 6.9 Silberschatz, Galvin and Gagne ©2018
 Interrupt-based Solution
▪ Entry section: disable interrupts
▪ Exit section: enable interrupts
▪ Will this solve the problem?
• What if the critical section is code that runs for an hour?
• Can some processes starve – never enter their critical section.
• What if there are two CPUs?

Operating System Concepts – 10th Edition 6.10 Silberschatz, Galvin and Gagne ©2018
 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

Operating System Concepts – 10th Edition 6.11 Silberschatz, Galvin and Gagne ©2018
 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

Operating System Concepts – 10th Edition 6.12 Silberschatz, Galvin and Gagne ©2018
 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:

Operating System Concepts – 10th Edition 6.13 Silberschatz, Galvin and Gagne ©2018
 Mutex Locks
▪ 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

Operating System Concepts – 10th Edition 6.14 Silberschatz, Galvin and Gagne ©2018
 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
▪ A Semaphore is a lower-level object. A semaphore is a non-
negative integer variable. The value of Semaphore indicates
the number of shared resources available in the system. The
value of semaphore can be modified only by two functions,
namely wait() and signal() operations (apart from the
initialization)

Operating System Concepts – 10th Edition 6.15 Silberschatz, Galvin and Gagne ©2018
 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
▪ A Monitor type high-level synchronization construct. It is an abstract
data type. The Monitor type contains shared variables and the set of
procedures that operate on the shared variable

Operating System Concepts – 10th Edition 6.16 Silberschatz, Galvin and Gagne ©2018
 Liveness

▪ Processes may have to wait indefinitely while trying to acquire a

synchronization tool such as a mutex lock or semaphore.
▪ Waiting indefinitely violates the progress and bounded-waiting criteria
discussed at the beginning of this chapter.
▪ Liveness refers to a set of properties that a system must satisfy to
ensure processes make progress.
▪ Indefinite waiting is an example of a liveness failure.

Operating System Concepts – 10th Edition 6.17 Silberschatz, Galvin and Gagne ©2018
 End of Chapter 6

Operating System Concepts – 10th Edition Silberschatz, Galvin and Gagne ©2018