College of Computers & IT

Dep. of IT

Operating
Systems
Lecture 4: Process
Synchronization
2019/2020 Prepared by: Dr. Rasha Bin-Thalab
 Lecture Out Lines
2

 Background
 The Critical-Section Problem
 Peterson’s Solution
 Synchronization Hardware
 Mutex Locks
 Semaphores
 Classic Problems of Synchronization
 Monitors
 Synchronization Examples
 Alternative Approaches
 Communication in client-server processes
 Background
3

 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
 Produces a new buffer and is decremented by the
 Producer-Consumer Problem – 1
4

 Paradigm for cooperating processes, producer

process produces information that is consumed by
a consumer process
 unbounded-buffer places no practical limit on the size
of the buffer
 bounded-buffer assumes that there is a fixed buffer
size
 Producer-Consumer Problem – 2
5

 Illustration of the problem:

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 counter that keeps track of the
number of full buffers. Initially, counter 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
 Producer & Consumer Example
6

Producer
Consumer
while (true) {
while (true) {
// produce an item in next produced
while (counter == 0);
/* do nothing */
while (counter == BUFFER_SIZE) ;
next_consumed = buffer[out];
/* do nothing */
out = (out + 1) % BUFFER_SIZE;
buffer[in] = next_produced;
counter--;
in = (in + 1) % BUFFER_SIZE;
// consume the item in next consumed
counter++;
}
}
Race counter++ could be implemented as


register1 = counter
register1 = register1 + 1
Condition
7 
counter = register1
counter-- could be implemented as
register2 = counter
register2 = register2 - 1
counter = 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
{counter = 6 }
S5: consumer execute counter = register2
 Critical Section Problem
8

 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
 Solution to Critical-Section Problem
9

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
 Peterson’s Solution
10

 Good algorithmic description of solving the problem

 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
 Algorithm to Process Pi
11

int turn;
boolean flag[2];
do {
flag[i] = true;
turn = j;
while (flag[j] && turn = = j);
critical section
flag[i] = false;
remainder section
} while (true);
 Critical section solution
12

 Hardware support for synchronization

 Software
 Mutex Lock
 Semaphores
 Synchronization Hardware
13

 The critical section problem could be solved easily in a

single-processor environment if we could disallow
interrupts to occur while a shared variable or resource
is being modified.
 We could be sure that the current sequence of
instructions would be allowed to execute in order
without pre-emption
 This solution is not feasible in a multiprocessor
environment.
 time consuming
 Mutex Lock
14

 As the synchronization hardware solution is not easy to

implement for everyone, a strict software approach
called Mutex Locks was introduced.
 In this approach, in the entry section of code, a LOCK is
acquired over the critical resources modified and used
inside critical section, and in the exit section that LOCK
is released.
 As the resource is locked while a process executes its
critical section hence no other process can access it.
 Semaphore
15

 Semaphore S – integer variable

 Can only be accessed via two indivisible (atomic)
operations
P(S): if S ≥ 1 then S := S - 1
 wait() and signal() else <block and enqueue the
 Originally called P() and V() process>;
 Definition of the wait() operation
V(S): if <some process is blocked on the
{ wait(S)
queue>
while (S <= 0); // busy wait
then <unblock a process>
} ;--S
else S := S + 1;
 Definition of the signal() operation
signal(S) { S++; }
 Semaphore Usage
16

 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 solve various synchronization problems

 Consider P1 and P2 that require S1 to happen before S2
Create a semaphore “synch” initialized to 0
:P1
;S1
;signal(synch)
:P2
;wait(synch)
;S2
 Can implement a counting semaphore S as a binary semaphore
 Semaphore exercises
17

Consider a system consisting of two processes P1 and P2, each process accessing two semaphores, S
and Q set to the value 1: What is the output if the processes executed concurrently?

P1 P2 Output

Wait(S) Wait(Q)

Wait(Q)

Printf(‘Good Bye’) Printf(‘Hello’)

Signal(S)

Signal(Q) Signal(Q)
 Communications in Client-Server
18
Systems

 Sockets
 Remote Procedure Calls
 Pipes
 Remote Method Invocation (Java)
 Sockets
19

 A socket is defined as an endpoint for communication

 Concatenation of IP address and port – a number
included at start of message packet to differentiate
network services on a host
 The socket 161.25.19.8:1625 refers to port 1625 on
host 161.25.19.8
 Communication consists between a pair of sockets
 All ports below 1024 are well known, used for standard
services
 Socket Communication
20
 Sockets in Java
21

 Three types of sockets

 Connection-oriented
(TCP)
 Connectionless
(UDP)
 MulticastSocket
class– data can be sent
to multiple recipients

 Consider this “Date”

server:
 Remote Procedure Calls
22

 Remote procedure call (RPC) abstracts procedure

calls between processes on networked systems
 Again uses ports for service differentiation
 Stubs – client-side proxy for the actual procedure on
the server
 The client-side stub locates the server and marshalls
the parameters
 The server-side stub receives this message, unpacks
the marshalled parameters, and performs the
procedure on the server
 Remote Procedure Calls
23
(Cont.)

 Data representation handled via External Data

Representation (XDL) format to account for
different architectures
 Big-endian and little-endian
 Remote communication has more failure scenarios
than local
 Messages can be delivered exactly once rather than at
most once
 OS typically provides a rendezvous (or matchmaker)
service to connect client and server
 Pipes
24

 Acts as a conduit allowing two processes to

communicate
 Issues:
 Is communication unidirectional or bidirectional?
 In the case of two-way communication, is it half or full-
duplex?
 Must there exist a relationship (i.e., parent-child) between
the communicating processes?
 Can the pipes be used over a network?
 Ordinary pipes – cannot be accessed from outside the
process that created it. Typically, a parent process
 Ordinary Pipes
25

 Ordinary Pipes allow communication in standard

producer-consumer style
 Producer writes to one end (the write-end of the pipe)
 Consumer reads from the other end (the read-end of
the pipe)
 Ordinary pipes are therefore unidirectional
 Require parent-child relationship between
communicating processes
 Named Pipes
26

 Named Pipes are more powerful than ordinary pipes

 Communication is bidirectional
 No parent-child relationship is necessary between the
communicating processes
 Several processes can use the named pipe for
communication
 Provided on both UNIX and Windows systems