Operating Systems

Lecture 5A Process Synchronization

1
Chapter Objectives
 To examine several classical process-synchronization
problems.
 To present both software and hardware solutions of the
critical-section problem.
 To explore several tools that are used to solve process
synchronization problems.

2
Outline
 Background
 Cooperating Processes
 The Bounded Buffer Producer-Consumer
Problem
 The Critical Section Problem
 Semaphores and Monitors
 Classical Problems of Synchronization

3
Motivation
Designing correct routines for controlling concurrent activities proved
to be one of the most difficult aspects of systems programming.
The growing importance of multicore systems has brought an

increased emphasis on developing multithreaded applications. In such

applications, several threads.
These applications are quite possibly sharing data and are running in

parallel on different processing cores.

Clearly, we want any changes that result from such activities not to

interfere with one another.

Because of the importance of this issue, we devote a major portion of

this chapter to process synchronization and coordination among
cooperating processes

4
Cooperating Processes
 Concurrent Processes can be
 Independent processes
 cannot affect or be affected by the execution of another process.
 Cooperating processes
 can affect or be affected by the execution of another process.
 Advantages of process cooperation:
 Information sharing
 Computation speedup
 Modularity
 Convenience(e.g. editing, printing, compiling)
 Concurrent execution requires
 process communication and process synchronization

5
Producer-Consumer Problem

 Paradigm for cooperating processes;

 producer process produces information that is consumed by a
consumer process.
 We need buffer of items that can be filled by producer and
emptied by consumer.
 Unbounded-buffer places no practical limit on the size of the buffer. Consumer may
wait, producer never waits.
 Bounded-buffer assumes that there is a fixed buffer size. Consumer waits for new
item, producer waits if buffer is full.
 Producer and Consumer must synchronize.

6
 Producer-Consumer Problem
 General Situation:
 One or more producers are generating data and placing these in a buffer

 A single consumer is taking items out of the buffer one at time

 The Problem:

 – Ensure that the Producer can’t add data into full buffer

and consumer can’t remove data from empty buffer.

7
Producer-Consumer Problem
 Problem: There is a set of resource buffers shared by
producer and consumer threads
  Producer inserts resources into the buffer set

 ◆ Output, disk blocks, memory pages, processes, etc.

  Consumer removes resources from the buffer set

 ◆ Whatever is generated by the producer

  Producer and consumer execute at different rates

8
Background

 Concurrent access to shared data may result in data

inconsistency.
 Maintaining data consistency requires mechanisms to ensure
the orderly execution of cooperating processes.
 What could go wrong???????

9
Race Condition
 A race condition occurs when multiple processes or threads read and write
data items so that the final result depends on the order of execution of
instructions in the multiple processes
 As a first example, suppose that two processes, P1 and P2, share the global
variable a. At some point in its execution, P1 updates a to the value 1, and at
some point in its execution, P2 updates a to the value 2. Thus, the two tasks
are in a race to write variable a.
 In this example, the “loser” of the race (the process that updates last)
determines the final value of a.

10
Race Conditions cont.
• Race condition: whenever the output depends
on the precise execution order of the processes!
• What solutions can we apply?
– prevent context switches by preventing interrupts
– make threads coordinate with each other to ensure mutual exclusion
in accessing critical sections of code

11
Race Conditions cont…
 To prevent race conditions, programmers use synchronization
primitives like locks, semaphores, or other mechanisms to ensure that
only one thread or process can access the shared resource or critical
section at a time.
 This is known as mutual exclusion or serialization, and it ensures that
each thread has exclusive access to the shared resource, preventing
conflicts and race conditions.
 In summary, race conditions can cause unpredictable behavior in
concurrent programs and can be prevented by ensuring that access
to shared resources or critical sections of code is properly
synchronized.

12
The Critical-Section Problem
 Consider a system consisting of n processes
{P0,P1, ...,Pn−1}.
 Each process has a segment of code, called a critical

section, in which the process may be changing common

variables, updating a table, writing a file, and so on.
 The important feature of the system is that, when one

process is executing in its critical section, no other

process is allowed to execute in its critical section.

 It cannot be executed by more than one process. Typically, the critical

section accesses a shared resource, such as a data structure, a peripheral
device, or a network connection, that does not allow multiple concurrent
accesses.

13
The Critical-Section Problem

14
The Critical-Section Problem
 Each process must request permission to enter its critical section.
 The section of code implementing this request is the entry section.
 The critical section may be followed by an exit section. The remaining code is
the remainder section.

15
The Critical-Section Problem
 N processes all competing to use shared data.
 Structure of process Pi ---- Each process has a code segment, called the critical section, in
which the shared data is accessed.
repeat
entry section /* enter critical section */
critical section /* access shared variables */
exit section /* leave critical section */
remainder section /* do other work */
until false
 Problem
 Ensure that when one process is executing in its critical section, no other process is allowed
to execute in its critical section.

16
Solution: Critical Section Problem -
Requirements
A solution to the critical-section problem must satisfy the following

Mutual Exclusion
 If process Pi is executing in its critical section, then no other
processes can be executing in their critical sections.
Progress
 If no process is executing in its critical section and there exists
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.
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.

17
How can we enforce mutual exclusion?
• What about using locks ?
• Locks solve the problem of exclusive access to
shared data.
– Acquiring a lock prevents concurrent access
– Expresses intention to enter critical section

• Assumption:
– Each each shared data item has an associated lock
– Every thread sets the right lock before accessing shared data!
– Every thread releases the lock after it is done!

18
Mutex Locks

19
Mutual exclusion (mutex) locks
• An abstract data type
• Used for synchronization
• The mutex is either:
– Locked (“the lock is held”)
– Unlocked (“the lock is free”)

20
Mutex lock operations
• Lock (mutex)
– Acquire the lock if it is free … and continue

– Otherwise wait until it can be acquired

• Unlock (mutex)
– Release the lock

– If there are waiting threads wake up one of them

21