Introduction to

Operating Systems
C-CS316 Spring 2024

LECTURE 06:
Process Synchronization
Dr. Basma Hassan Dr. Ahmed Salama
[email protected] [email protected]

Faculty of Computing and Information Sciences

1
Faculty of Computing and Information Sciences
2
Chapters 6 &7: Process Synchronization
Producer-Consumer Problem
The Critical-Section Problem
Peterson’s Solution
Hardware Support for Synchronization
Mutex Locks
Semaphores
Monitors
Liveness
Classic Problems of Synchronization

Faculty of Computing and Information Sciences

3
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

Faculty of Computing and Information Sciences

4
Producer-Consumer Problem

• Paradigm for cooperating processes:

• producer process produces information that is consumed by a
consumer process
• Two variations:
Unbounded-Buffer

Bounded-buffer
Places no limit on the size of Assumes that there is a fixed
the buffer buffer size

Producer must wait if all buffers

Producer never waits
are full

Consumer waits if there is no Consumer waits if there is no

buffer to consume buffer to consume

Faculty of Computing and Information Sciences

5
Bounded-Buffer: Shared-Memory Solution

• Shared data
#define BUFFER_SIZE 10
typedef struct {
. . . Producer
Buffer
} item;

item buffer[BUFFER_SIZE];
int in = 0; Consumer
int out = 0;

Faculty of Computing and Information Sciences

6
Producer-Consumer Processes: Shared Memory

Producer Process Consumer Process

item next_produced; item next_consumed;

while (true) { while (true) {

/* produce an item in next produced */ while (in == out)
; /* do nothing */
while (((in + 1) % BUFFER_SIZE) == out)
; /* do nothing */ next_consumed = buffer[out];
out = (out + 1) % BUFFER_SIZE;
buffer[in] = next_produced;
in = (in + 1) % BUFFER_SIZE; /* consume the item in next consumed */
} }

Solution is correct, but can only use BUFFER_SIZE-1 elements 

Faculty of Computing and Information Sciences

7
What about Filling all the Buffers?

• 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.
• The integer counter is incremented by the producer.
• The integer counter is and is decremented by the consumer.

Faculty of Computing and Information Sciences

8
Producer-Consumer Processes: Counter
Producer
Buffer

Consumer

Producer Process Consumer Process

while (true) { while (true) {
/* produce an item in next produced */ while (counter == 0)
; /* do nothing */
while (counter == BUFFER_SIZE)
; /* do nothing */ next_consumed = buffer[out];
out = (out + 1) % BUFFER_SIZE;
buffer[in] = next_produced;
in = (in + 1) % BUFFER_SIZE; counter--;

counter++; /* consume the item in next consumed */

} }

Faculty of Computing and Information Sciences

9
Producer-Consumer Processes: Race Condition
• counter++ could be implemented as
Question
register1 = counter
register1 = register1 + 1
why was there no race condition
counter = register1 in the first solution (where at
most N – 1) buffers can be filled?
• counter-- could be implemented as
register2 = counter
register2 = register2 - 1
counter = register2

• Consider this execution interleaving with initially: counter 5

S0: register1 = counter register1 5

S1: register1 = register1 + 1 register1 6
S2: register2 = counter register2 5
S3: register2 = register2 - 1 register2 4
S4: counter = register1 counter 6
S5: counter = register2 counter 4

Faculty of Computing and Information Sciences

10
Race Condition: Another Example
• Processes P0 and P1 are creating child
processes using the fork() system call

• Race condition on kernel variable

next_available_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!

Faculty of Computing and Information Sciences

11
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

Faculty of Computing and Information Sciences

12
Critical Region Illustrated

Faculty of Computing and Information Sciences

13
Critical-Section Problem (Cont.)

• General structure of process Pi

while (true){

entry section

critical section

exit section

remainder section

Faculty of Computing and Information Sciences

14
Critical-Section Problem (Cont.)
• Requirements for solution to critical-section problem
Mutual If process Pi is executing in its critical section, then no other processes
Safety

Exclusion can be executing in their critical sections

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
Liveness

indefinitely

Bounded A bound must exist on the number of times that other processes are
Waiting allowed to enter their critical sections after a process has made a request
to enter its critical section and before that request is granted

Rule of thumb:
When designing a concurrent algorithm, worry about safety first but don’t forget liveness!

Faculty of Computing and Information Sciences

15
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?

Faculty of Computing and Information Sciences

16
Software Solution 1: Alternation (Two process solution)

• Assume that the load and store machine-language

instructions are atomic
• that is, cannot be interrupted store

CPU

• The two processes share one variable: load

• int turn;

• The variable turn indicates whose turn it is to enter the

critical section
• initially, the value of turn is set to i

Faculty of Computing and Information Sciences

17
Algorithm for Process Pi

while (true){

Busy waiting while (turn == j);

(spinning)

/*critical section*/

turn = j;

/*remainder section*/

Faculty of Computing and Information Sciences

18
Correctness of the Software Solution
P0 P1
while (true){ while (true){
E while (turn == 1); E while (turn == 0);
C /*critical section*/ C /*critical section*/
X turn = 1; X turn = 0;
R /*remainder section*/ Infinite R /*remainder section*/
loop
} }

Consider this execution interleaving with initially: turn = 0

P1 (E) P0 (E,C,X) P1 (C,X) P0 (R) P1 (R,E)

→ Does this solution satisfy the safety and liveness requirements?

Faculty of Computing and Information Sciences

19
Correctness of the Software Solution

• Mutual exclusion is preserved

Pi enters critical section only if:
turn = i
and turn cannot be both 0 and 1 at the same time

• What about the Progress requirement?

• Is not satisfied
• What about the Bounded-waiting requirement?
• Is met

Faculty of Computing and Information Sciences

20
Peterson’s Solution (Two process solution)

• The two processes share two variables:

Pi
int turn; indicates whose turn
while (true){
it is to enter the
boolean flag[2] critical section
flag[i] = true;
turn = j;
array is used to implies that
indicate if a process is process Pi is ready! while (flag[j] && turn == j);
ready to enter the
critical section /*critical section*/

flag[i] = false;

/*remainder section*/

Faculty of Computing and Information Sciences

21
Correctness of Peterson’s Solution
Pi
• Consider this execution interleaving while (true){
with initially:
flag[i] = true;
turn = 0, flag = {false, false} turn = j;
while (flag[j] && turn == j);

P1 (E) P0 (E) P1 (C,X) P0 (C,X,R) P1 (R,E) /*critical section*/

flag[i] = false;

/*remainder section*/
}

→ Does this solution satisfy the safety and liveness requirements?

Faculty of Computing and Information Sciences

22
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

Faculty of Computing and Information Sciences

23
Peterson’s Solution and Modern Architecture

• 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

• For single-threaded this is ok as the result will always be

the same.
• For multithreaded the reordering may produce inconsistent
or unexpected results!

Faculty of Computing and Information Sciences

24
Modern Architecture Example

• Two threads share the data: Thread 1 Thread 2

boolean flag = false; while (!flag); x = 100;
int x = 0; print x flag = true

What is the expected output?

• However, since the variables flag and x are independent of each

other, the instructions for Thread 2 may be reordered as follows:
flag = true
x = 100;

• If this occurs, the output may be 0!

Faculty of Computing and Information Sciences

25
Peterson’s Solution Revisited
• The effects of instruction reordering in Peterson’s Solution

• This allows both processes to be in their critical section at the same

time!

• To ensure that Peterson’s solution will work correctly on modern

computer architecture we must use Memory Barrier.
Faculty of Computing and Information Sciences
26
Memory Barrier Instructions

• A memory barrier is an instruction that forces any change in

memory to be propagated (made visible) to all other processors.

• When a memory barrier instruction is performed, the system

ensures that…
• all loads and stores are completed before any subsequent load or store
operations are performed.

• Therefore, even if instructions were reordered…

• the memory barrier ensures that the store operations are completed in
memory and visible to other processors before future load or store
operations are performed.

Faculty of Computing and Information Sciences

27
Memory Barrier Example

• Returning to the two threads example

• Adding a memory barrier to the following instructions ensures Thread 1 outputs
100:
Thread 1 Thread 2
while (!flag) x = 100;
memory_barrier(); memory_barrier();
print x flag = true

we are guaranteed that the value we ensure that the assignment to

of flag is loaded before the x occurs before the assignment
value of x. flag.

Faculty of Computing and Information Sciences

28
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

• Other forms of hardware support:

• Hardware instructions
• Atomic variables

Faculty of Computing and Information Sciences

29
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 (CAS)

Faculty of Computing and Information Sciences

30
The test_and_set Instruction

• Definition
boolean test_and_set (boolean *flag){
boolean org_value = *flag;
*flag = true;
return org_value;
}

• Properties
• Executed atomically
• Returns the original value of passed parameter
• Set the new value of passed parameter to true

Faculty of Computing and Information Sciences

31
The compare_and_swap Instruction

• Definition
int compare_and_swap(int *value, int expected, int new_value){
int temp = *value;
if (*value == expected)
*value = new_value;
return temp;
}

• Properties
• Executed atomically
• Returns the original value of passed parameter value
• Set the variable value the value of the passed parameter new_value but only if
*value == expected is true.
• That is, the swap takes place only under this condition.

Faculty of Computing and Information Sciences

32
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

Faculty of Computing and Information Sciences

33
Solution to CS Problem Using Mutex Locks
acquire() {
while (!available)
while (true) { ; /* busy wait */
available = false;
acquire lock }

critical section

release lock
release() {
remainder section
available = true;
}
}

Implementation of locks has critical sections, too!

Calls to acquire() and release() must be atomic

→usually implemented via hardware atomic instructions

Faculty of Computing and Information Sciences

34
Mutex Lock Solution Using test_and_set()
• Shared Boolean variable lock, initialized to false

• Solution:
acquire() {
while (test-and-set(&lock))
; /* busy wait */
}

release() {
lock = false;
}

Faculty of Computing and Information Sciences

35
Mutex Lock Solution Using compare_and_swap

• Shared integer variable lock, initialized to 0

• Solution:
acquire() {
while (compare_and_swap(&lock, 0, 1) != 0)
; /* busy wait */
}

release() {
lock = 0;
}

Faculty of Computing and Information Sciences

36
Spinlock

• Mutex lock solution requires busy waiting

• This lock therefore called a spinlock

• The problem with spinlocks is that they are wasteful

• Wastes CPU cycles
• If a thread is spinning on a lock, then the thread holding the lock
cannot make progress (on a uniprocessor)
• Longer the CS, the longer the spin, greater the chance for lock
holder to be interrupted

Faculty of Computing and Information Sciences

37
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 atomic operations, wait( ) and signal( )
• Wait is originally called P( ) (after the Dutch word “Proberen” (to try)
• Signal is originally called and V( ) after the Dutch word “Verhogen” (to
increment)

Definition of the wait( ) operation Definition of the signal( ) operation

wait(S) { signal(S) {
while (S <= 0) S++;
; // busy wait }
S--;
}

Faculty of Computing and Information Sciences

38
Semaphore Types

• Binary Semaphore
• Integer value can range only between 0 and 1 → Count = 1
• Same as a mutex lock
• Represents single access to a resource
• Count = 1

• Counting Semaphore
• Integer value can range over an unrestricted domain → Count = N
• Represents a resource with many units available
• Multiple threads can pass the semaphore

Faculty of Computing and Information Sciences

39
Semaphore Usage 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;

Faculty of Computing and Information Sciences

40
Semaphore Implementation with no Busy waiting

• 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

Faculty of Computing and Information Sciences

41
Implementation with no Busy waiting (Cont.)

• Waiting queue
typedef struct {
int value;
struct process *list;
} semaphore;

wait(semaphore *S) { signal(semaphore *S) {

S->value--; S->value++;
if (S->value < 0) { if (S->value <= 0) {
add this process to S->list; remove a process P from S->list;
block(); // put to sleep wakeup(P);
} }
} }

Faculty of Computing and Information Sciences

42
Problems with Semaphores

• Incorrect use of semaphore operations:

• signal(mutex) … wait(mutex)
• wait(mutex) … wait(mutex)
• Omitting of wait(mutex)and/or signal(mutex)

• These – and others – are examples of what can occur when

semaphores and other synchronization tools are used
incorrectly.

Faculty of Computing and Information Sciences

43
 End of Lecture!
Thanks for your Attention!

Faculty of Computing and Information Sciences

44