Process

Synchronization
Chenyang Zhu
Concurrency
OS supports multi-programming
 In single-processor system, processes are interleaved in time
 In multiple-process system, processes execution is not only interleaved,
but also overlapped in time
Both are concurrent processing
Present same problems: relative speed of execution of
processes cannot be predicted …
Concurrency: challenges
Present same problems: relative speed of execution of
processes cannot be predicted …
 Concurrent access to shared data may result in data inconsistency
 E.g. two processes both make use of same global variable (in
shared memory segment) and perform reads and writes
 The order in which the various reads and writes are executed is
critical
Challenges in resource allocation: deadlock prevention
Locating programming error is difficult: sometimes not
deterministic and not reproducible
Example
Suppose processes P1, and P2 share global variable a
 At some point, P1 updates a to the value 1
 At some point, P2 updates a to the value 2
The two tasks are in a race to write variable a
The loser of the race (the process that updates last) determines
the final value of a
If multiple processes or threads read and write data items so that
final result depends on the order of execution of instructions in
the multiple processes, we have a race condition
Race condition is bad !
Process synchronization is about how to avoid race condition
 Race Conditions

Figure 2-21. Two processes want to access

shared memory at the same time.
Tanenbaum, Modern Operating Systems 3 e, (c) 2008 Prentice-Hall, Inc. All rights reserved. 0-13-6006639
Race Condition
A race condition occurs when
 Multiple processes access and manipulate same data
concurrently
 Outcome of execution depends on the particular order in which
the access takes place.
Critical section/region
 the segment of code where process modifying shared/common
variables (tables, files)
Critical section problem, mutual exclusion problem
 No two processes can execute in critical sections at the same
time
Conditions required to avoid race condition
 Mutual Exclusion: No two processes may be
simultaneously inside their critical regions.
 No assumptions may be made about speeds or the
number of CPUs.
 No process running outside its critical region may block
other processes (progress)
 Bounded Waiting: No process should have to wait forever
to enter its critical region (no deadlock or starvation)

Tanenbaum, Modern Operating Systems 3 e, (c) 2008 Prentice-Hall, Inc. All rights reserved. 0-13-6006639
 Critical Regions

Figure 2-22. Mutual exclusion using critical regions.

Tanenbaum, Modern Operating Systems 3 e, (c) 2008 Prentice-Hall, Inc. All rights reserved. 0-13-6006639
Mutual Exclusion with Busy Waiting

Proposals for achieving mutual exclusion:

• Disabling interrupts
• Lock variables
• Strict alternation
• Peterson's solution
• The TSL instruction

Tanenbaum, Modern Operating Systems 3 e, (c) 2008 Prentice-Hall, Inc. All rights reserved. 0-13-6006639
Approach to mutual exclusion
Software approach
 No support from programming language or OS
 Prone to high processing overhead and bugs
 E.g., Peterson’s Algorithm
Hardware approach
 Special-purpose machine instructions
 Less overhead, machine independent
OS or programming language
 Strict Alternation

Figure 2-23. A proposed solution to the critical region problem.

(a) Process 0. (b) Process 1. In both cases, be sure to note
the semicolons terminating the while statements.
Tanenbaum, Modern Operating Systems 3 e, (c) 2008 Prentice-Hall, Inc. All rights reserved. 0-13-6006639
 Peterson's Solution

Figure 2-24. Peterson’s solution for achieving mutual exclusion.

Tanenbaum, Modern Operating Systems 3 e, (c) 2008 Prentice-Hall, Inc. All rights reserved. 0-13-6006639
Peterson’s Solution
Purely software based solution
Might failed for modern computer architecture
 Instruction reordering
 Complier optimization
Hardware Solution
Many systems provide hardware support for critical
section code
One approach
 simply disable interrupts just before enters critical section
 enable interrupts just before exits critical section
 code within critical section would execute without preemption
Problems
 On multiprocessor systems, need to disable interrupts on all
processors => too efficient
 What if a process spends a long time or forever in critical
section?
 Should be extremely careful when using this approach
Hardware Solution
Modern machines provide special atomic hardware
instructions
 atomic: non-interruptable
 If there are executed simultaneously (each on a diff. CPU), they will be
executed sequentially in some arbitrary order.
Two type of atomic hardware instructions
 test memory word and set value, TestAndSet()
 swap contents of two memory words, Swap()
Summary: Machine-instruction
approach
Applicable to single processor or multiple processors
system
Simple and easy to verify
Can support multiple critical section
 Each guarded by its own variable (lock)
Busy waiting is used
Potential Starvation
Potential deadlock
OS and Programming Language
Approach
Semaphore
Mutex
Condition variables
Monitor
Event flags
Mailboxes/Messages: block send/receive…
Spinlocks
…
Fundamentally, multiple processes can cooperate (synchronize)
through simple signals:
 A process can be forced to stop at a specific location until it receives a
specific signal
Semaphore
1 : an apparatus for visual signaling (as by the position of
one or more movable arms)
2 : a system of visual signaling by two flags held one in each
hand
Signal
 an act, event, or watchword that has been agreed on as the
occasion of concerted action
 something that conveys notice or warning
Semaphore as General Synchronization Tool
Binary semaphore – integer value can range only between
0 and 1; can be simpler to implement
 Also known as mutex (mutual-exclusive) locks
mutual exclusion using binary semaphore
 Semaphore S; // initialized to 1
 wait (S);
 Critical Section
 signal (S);
 Remainder Section;
 How about other requirements: progress, bounded waiting?
 Semaphore as General Synchronization Tool
Binary semaphore – integer value can range only between
0 and 1; can be simpler to implement
Counting semaphore – integer value can range over an
unrestricted domain
 Typically initialized to the number of free resources.
 Processes/Threads:
 Signal(s) when resources are added
 Wait(s) when resources are removed.
 When value becomes zero, no more resources are present. Process that try
to decrement semaphore is block until value becomes greater than zero.
 Let’s see the usage of counting semaphore with an example.
 Semaphore Implementation
Must guarantee that no two processes can execute wait
() and signal () on same semaphore at same time
Thus, implementation becomes critical section problem:
 wait and signal code are placed in critical section.
 ok to use busy waiting to implement this critical section:
 implementation code is short
 little busy waiting if critical section rarely occupied
Busy waiting not a good solution for applications that
spend lots of time in critical sections
 Lots of busy waiting
 Mutexes
Simple version of Semaphore
Two states: unlock and lock
Mutexes in Pthreads (1)

Figure 2-30. Some of the Pthreads calls relating to mutexes.

Tanenbaum & Bo,Modern Operating Systems:4th ed., (c) 2013 Prentice-Hall, Inc. All rights reserved.
 Monitors
Monitor is a programming-language construct that
provides equivalent functionality to that of semaphores
and that is easier to control.
Implemented in a number of programming languages,
including
 Concurrent Pascal, Pascal-Plus,
 Modula-2, Modula-3, and Java.
Mutexes in Pthreads (2)

Figure 2-31. Some of the Pthreads calls relating

to condition variables.
Tanenbaum & Bo,Modern Operating Systems:4th ed., (c) 2013 Prentice-Hall, Inc. All rights reserved.
Monitors
Monitor is a programming-language construct that
provides equivalent functionality to that of semaphores
and that is easier to control.
Implemented in a number of programming languages,
including
 Concurrent Pascal, Pascal-Plus,
 Modula-2, Modula-3, and Java.

58
Main characteristics of Monitor
Like a Abstract Data Type (as studied in Data structure)
 1. Local data variables are accessible only by monitor (private
data member of a class in C++)
 2. Process enters monitor by invoking one of its procedures
(public member function of a class)
 3. Only one process may be executing in monitor at a time
Shared data structure can be protected by placing it in a
monitor
Access shared data only through monitor procedure =>
not scattered through codes (easier to verify)

59
Synchronization in Monitor
Monitor supports synchronisation by containing condition
variables
 only accessible by monitor.
Condition variable: a special data type in monitors, with
two operations:
 cwait(c): suspend calling process on condition c
 Put calling process on a waiting queue associated with
condition c
 csignal(c): resume some process that was blocked
after a cwait() operation on condition c
 Wake up a process on waiting queue associated with condition
c

60
Classical Problems – The dining
philosophers problem

• Figure 2-45. Lunch time in the Philosophy

Department.
60
The Dining Philosophers Problem (2)

Figure 2-46. A nonsolution to the dining philosophers problem.

Tanenbaum & Bo,Modern Operating Systems:4th ed., (c) 2013 Prentice-Hall, Inc. All rights reserved.
The Dining Philosophers Problem (3)

Figure 2-47. A solution to the dining philosophers problem.

Tanenbaum & Bo,Modern Operating Systems:4th ed., (c) 2013 Prentice-Hall, Inc. All rights reserved.
The Dining Philosophers Problem (4)

Figure 2-47. A solution to the dining philosophers problem.

Tanenbaum & Bo,Modern Operating Systems:4th ed., (c) 2013 Prentice-Hall, Inc. All rights reserved.
The Dining Philosophers Problem (5)

Figure 2-47. A solution to the dining philosophers problem.

Tanenbaum & Bo,Modern Operating Systems:4th ed., (c) 2013 Prentice-Hall, Inc. All rights reserved.
The Readers and Writers Problem (1)

Figure 2-48. A solution to the readers and writers problem.

Tanenbaum & Bo,Modern Operating Systems:4th ed., (c) 2013 Prentice-Hall, Inc. All rights reserved.
The Readers and Writers Problem (2)

Figure 2-48. A solution to the readers and writers problem.

Tanenbaum & Bo,Modern Operating Systems:4th ed., (c) 2013 Prentice-Hall, Inc. All rights reserved.
 End

Tanenbaum & Bo,Modern Operating Systems:4th ed., (c) 2013

Prentice-Hall, Inc. All rights reserved.