Processes Synchronization - Part I

Amir H. Payberah
[email protected]
Nov. 14, 2023
Processes Synchronization

1 / 46
Background

I Processes can execute concurrently.

2 / 46
Background

I Processes can execute concurrently.

https://tinyurl.com/2yjcpx75

2 / 46
Background

I Processes can execute concurrently.

I Concurrent access to shared data may result in data inconsistency.

https://tinyurl.com/2yjcpx75

2 / 46
Background

I Processes can execute concurrently.

I Concurrent access to shared data may result in data inconsistency.
I Maintaining data consistency requires mechanisms to ensure the orderly
execution of cooperating processes.

https://tinyurl.com/2yjcpx75

2 / 46
Producer-Consumer Problem

I The producer-consumer problem.

3 / 46
Producer-Consumer Problem

I The producer-consumer problem.

I Having an integer counter that keeps track of the number of items in the
buffers.

3 / 46
Producer-Consumer Problem

I The producer-consumer problem.

I Having an integer counter that keeps track of the number of items in the
buffers.
• Initially, counter is set to 0.

3 / 46
Producer-Consumer Problem

I The producer-consumer problem.

I Having an integer counter that keeps track of the number of items in the
buffers.
• Initially, counter is set to 0.
• The producer produces a new item: increment the counter

3 / 46
Producer-Consumer Problem

I The producer-consumer problem.

I Having an integer counter that keeps track of the number of items in the
buffers.
• Initially, counter is set to 0.
• The producer produces a new item: increment the counter
• The consumer consumes an item: decrement the counter

3 / 46
Producer

I Producer

while (true) {
/* produce an item in next produced */

while (counter == BUFFER_SIZE); /* do nothing */

buffer[in] = next_produced;

in = (in + 1) % BUFFER_SIZE;

counter++;
}

4 / 46
Consumer

I Consumer

while (true) {
while (counter == 0); /* do nothing */

next_consumed = buffer[out];

out = (out + 1) % BUFFER_SIZE;

counter--;
/* consume the item in next consumed */
}

5 / 46
Race Condition

I counter++ could be implemented as

register1 = counter
register1 = register1 + 1
counter = register1

6 / 46
Race Condition

I counter++ could be implemented as

register1 = counter
register1 = register1 + 1
counter = register1
I counter-- could be implemented as
register2 = counter
register2 = register2 - 1
counter = register2

6 / 46
Race Condition

I counter++ could be implemented as

register1 = counter
register1 = register1 + 1
counter = register1
I counter-- could be implemented as
register2 = counter
register2 = register2 - 1
counter = register2
I Consider this execution interleaving with count = 5 initially:

6 / 46
Race Condition

I counter++ could be implemented as

register1 = counter
register1 = register1 + 1
counter = register1
I counter-- could be implemented as
register2 = counter
register2 = register2 - 1
counter = register2
I Consider this execution interleaving with count = 5 initially:
S0: producer: register1 = counter: register1 = 5

6 / 46
Race Condition

I counter++ could be implemented as

register1 = counter
register1 = register1 + 1
counter = register1
I counter-- could be implemented as
register2 = counter
register2 = register2 - 1
counter = register2
I Consider this execution interleaving with count = 5 initially:
S0: producer: register1 = counter: register1 = 5
S1: producer: register1 = register1 + 1: register1 = 6

6 / 46
Race Condition

I counter++ could be implemented as

register1 = counter
register1 = register1 + 1
counter = register1
I counter-- could be implemented as
register2 = counter
register2 = register2 - 1
counter = register2
I Consider this execution interleaving with count = 5 initially:
S0: producer: register1 = counter: register1 = 5
S1: producer: register1 = register1 + 1: register1 = 6
S2: consumer: register2 = counter: register2 = 5

6 / 46
Race Condition

I counter++ could be implemented as

register1 = counter
register1 = register1 + 1
counter = register1
I counter-- could be implemented as
register2 = counter
register2 = register2 - 1
counter = register2
I Consider this execution interleaving with count = 5 initially:
S0: producer: register1 = counter: register1 = 5
S1: producer: register1 = register1 + 1: register1 = 6
S2: consumer: register2 = counter: register2 = 5
S3: consumer: register2 = register2 - 1: register2 = 4

6 / 46
Race Condition

I counter++ could be implemented as

register1 = counter
register1 = register1 + 1
counter = register1
I counter-- could be implemented as
register2 = counter
register2 = register2 - 1
counter = register2
I Consider this execution interleaving with count = 5 initially:
S0: producer: register1 = counter: register1 = 5
S1: producer: register1 = register1 + 1: register1 = 6
S2: consumer: register2 = counter: register2 = 5
S3: consumer: register2 = register2 - 1: register2 = 4
S4: producer: counter = register1: counter = 6

6 / 46
Race Condition

I counter++ could be implemented as

register1 = counter
register1 = register1 + 1
counter = register1
I counter-- could be implemented as
register2 = counter
register2 = register2 - 1
counter = register2
I Consider this execution interleaving with count = 5 initially:
S0: producer: register1 = counter: register1 = 5
S1: producer: register1 = register1 + 1: register1 = 6
S2: consumer: register2 = counter: register2 = 5
S3: consumer: register2 = register2 - 1: register2 = 4
S4: producer: counter = register1: counter = 6
S5: consumer: counter = register2: counter = 4

6 / 46
What’s The Output?

int counter = 0;

void* thread_func(void *arg) {

counter++;
printf("Job %d started.\n", counter);
sleep(2);
printf("Job %d finished.\n", counter);

return NULL;
}

int main(void) {
pthread_t t1, t2;

pthread_create(&t1, NULL, &thread_func, NULL);

pthread_create(&t2, NULL, &thread_func, NULL);

pthread_join(t1, NULL);
pthread_join(t2, NULL);

return 0;
}

7 / 46
What’s The Output?

Job 1 started.
Job 2 started.
Job 2 finished.
Job 2 finished.

8 / 46
The Critical-Section (CS)
Problem

9 / 46
The Critical-Section Problem (1/2)

I Consider system of n processes {p0 , p1 , · · · , pn−1 }.

10 / 46
The Critical-Section Problem (1/2)

I Consider system of n processes {p0 , p1 , · · · , pn−1 }.

I Each process has CS segment of code.

10 / 46
The Critical-Section Problem (1/2)

I Consider system of n processes {p0 , p1 , · · · , pn−1 }.

I Each process has CS segment of code.

• Process may be changing common variables, updating table, writing file, etc.

10 / 46
The Critical-Section Problem (1/2)

I Consider system of n processes {p0 , p1 , · · · , pn−1 }.

I Each process has CS segment of code.

• Process may be changing common variables, updating table, writing file, etc.
• When one process in CS, no other may be in its CS.

10 / 46
The Critical-Section Problem (2/2)

I Each process must ask permission to enter CS in entry section, may follow
CS with exit section, then remainder section.

11 / 46
The Critical-Section Problem (2/2)

I Each process must ask permission to enter CS in entry section, may follow
CS with exit section, then remainder section.
I General structure of process Pi is below:

11 / 46
CS Problem Solution Requirements (1/3)

I Mutual Exclusion: if process Pi is executing in its CS, then no other

processes can be executing in their CSs.

12 / 46
CS Problem Solution Requirements (2/3)

I Progress: if no process is executing in its CS and there exist some pro-

cesses that wish to enter their CS, then the selection of the processes
that will enter the CS next cannot be postponed indefinitely.

13 / 46
CS Problem Solution Requirements (3/3)

I Bounded Waiting: a bound must exist on the number of times that

other processes are allowed to enter their CSs after a process has made
a request to enter its CS and before that request is granted.

14 / 46
CS Solutions

I Peterson’s solution

I Mutex lock

I Semaphore

15 / 46
Peterson’s Solution

16 / 46
Peterson’s Solution

I Two-process solution.

17 / 46
Peterson’s Solution

I Two-process solution.
I The two processes share two variables:
• int turn
• boolean flag[2]

17 / 46
Peterson’s Solution

I Two-process solution.
I The two processes share two variables:
• int turn
• boolean flag[2]

I turn: indicates whose turn it is to enter the CS.

17 / 46
Peterson’s Solution

I Two-process solution.
I The two processes share two variables:
• int turn
• boolean flag[2]

I turn: indicates whose turn it is to enter the CS.

I flag: indicates if a process is ready to enter the CS, i.e.,

flag[i] = true implies that process Pi is ready.

17 / 46
Algorithm for Process Pi

18 / 46
CS Requirements

I Provable that the three CS requirement are met:

19 / 46
CS Requirements

I 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

19 / 46
CS Requirements

I 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.

19 / 46
CS Requirements

I 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.

19 / 46
Mutex Locks

20 / 46
Mutex Locks

I Protect a CS by first acquire() a lock then release() the lock.

• Boolean variable indicating if lock is available or not.

21 / 46
Mutex Locks

I Protect a CS by first acquire() a lock then release() the lock.

• Boolean variable indicating if lock is available or not.

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

• Usually implemented via hardware atomic instructions.

21 / 46
Mutex Locks

I Protect a CS by first acquire() a lock then release() the lock.

• Boolean variable indicating if lock is available or not.

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

• Usually implemented via hardware atomic instructions.

I But this solution requires busy waiting.

• This lock therefore called a spinlock.

21 / 46
acquire() and release()

acquire() {
while (!available); /* busy wait */

available = false;
}

release() {
available = true;
}

22 / 46
23 / 46
pthread Mutexes

I Mutexes are represented by the pthread mutex t object.

24 / 46
pthread Mutexes

I Mutexes are represented by the pthread mutex t object.

I pthread mutex lock() locks (acquires) a pthreads mutex.

int pthread_mutex_lock(pthread_mutex_t *mutex);

24 / 46
pthread Mutexes

I Mutexes are represented by the pthread mutex t object.

I pthread mutex lock() locks (acquires) a pthreads mutex.

int pthread_mutex_lock(pthread_mutex_t *mutex);

I pthread mutex unlock() unlocks (releases) a pthreads mutex.

int pthread_mutex_unlock(pthread_mutex_t *mutex);

24 / 46
What’s The Output?
int counter = 0;
pthread_mutex_t lock;

void* thread_func(void *arg) {

pthread_mutex_lock(&lock);
counter++;
printf("Job %d started.\n", counter);
sleep(2);
printf("Job %d finished.\n", counter);
pthread_mutex_unlock(&lock);

return NULL;
}

int main(void) {
pthread_t t1, t2;

pthread_mutex_init(&lock, NULL);

pthread_create(&t1, NULL, &thread_func, NULL);

pthread_create(&t2, NULL, &thread_func, NULL);

pthread_join(t1, NULL);
pthread_join(t2, NULL);

pthread_mutex_destroy(&lock);

return 0;
}

25 / 46
What’s The Output?

Job 1 started.
Job 1 finished.
Job 2 started.
Job 2 finished.

26 / 46
Semaphores

27 / 46
Semaphore

I Synchronization tool that provides more sophisticated ways (than Mutex

locks) for process to synchronize their activities.

28 / 46
Semaphore

I Synchronization tool that provides more sophisticated ways (than Mutex

locks) for process to synchronize their activities.

I Semaphore S: integer variable.

I Accessed via two atomic operations: wait() and signal()

28 / 46
wait() and signal()

wait(S) {
while (S <= 0); // busy wait

S--;
}

signal(S) {
S++;
}

29 / 46
Counting and Binary Semaphore

I Counting semaphore: integer value can range over an unrestricted domain.

30 / 46
Counting and Binary Semaphore

I Counting semaphore: integer value can range over an unrestricted domain.

I Binary semaphore: integer value can range only between 0 and 1.

• Same as a mutex lock.

30 / 46
Semaphore Usage (1/2)

I Initialize the semaphore to the number of available resources.

31 / 46
Semaphore Usage (1/2)

I Initialize the semaphore to the number of available resources.

I Call wait() before using a resource.

31 / 46
Semaphore Usage (1/2)

I Initialize the semaphore to the number of available resources.

I Call wait() before using a resource.

I Call signal() after releasing a resource.

31 / 46
Semaphore Usage (1/2)

I Initialize the semaphore to the number of available resources.

I Call wait() before using a resource.

I Call signal() after releasing a resource.

I If S = 0: all resources are used, and processes that wish to use a resource
will block until the count becomes greater than 0.

31 / 46
Semaphore Usage (2/2)

I Consider P1 and P2 that require C1 to happen before C2.

32 / 46
Semaphore Usage (2/2)

I Consider P1 and P2 that require C1 to happen before C2.

I Create a semaphore S initialized to 0.

// Process P1
C1;
signal(S);

// Process P2
wait(S);
C2;

32 / 46
Semaphore Usage (2/2)

I Consider P1 and P2 that require C1 to happen before C2.

I Create a semaphore S initialized to 0.

// Process P1
C1;
signal(S);

// Process P2
wait(S);
C2;

I The implementation still suffers from busy waiting.

32 / 46
Semaphore Implementation with no Busy Waiting (1/2)

I With each semaphore there is an associated waiting queue.

33 / 46
Semaphore Implementation with no Busy Waiting (1/2)

I With each semaphore there is an associated waiting queue.

I Each entry in a waiting queue has two data items:

• Value (of type integer).
• Pointer to next record in the list.

33 / 46
Semaphore Implementation with no Busy Waiting (1/2)

I With each semaphore there is an associated waiting queue.

I Each entry in a waiting queue has two data items:

• Value (of type integer).
• Pointer to next record in the list.

typedef struct {
int value;
struct process *list;
} semaphore;

33 / 46
Semaphore Implementation with no Busy Waiting (2/2)

I block: place the process invoking the operation on the appropriate wait-
ing queue.
I wakeup: remove one of processes in the waiting queue and place it in
the ready queue.

34 / 46
Semaphore Implementation with no Busy Waiting (2/2)

I block: place the process invoking the operation on the appropriate wait-
ing queue.
I wakeup: remove one of processes in the waiting queue and place it in
the ready queue.
wait(semaphore *S) {
S->value--;
if (S->value < 0) {
// add this process to S->list;
block();
}
}

34 / 46
Semaphore Implementation with no Busy Waiting (2/2)

I block: place the process invoking the operation on the appropriate wait-
ing queue.
I wakeup: remove one of processes in the waiting queue and place it in
the ready queue.
wait(semaphore *S) {
S->value--;
if (S->value < 0) {
// add this process to S->list;
block();
}
}

signal(semaphore *S) {
S->value++;
if (S->value <= 0) {
// remove a process P from S->list;
wakeup(P);
}
}

34 / 46
Deadlock

I Deadlock: two or more processes are waiting indefinitely for an event

that can be caused by only one of the waiting processes.

35 / 46
Deadlock

I Deadlock: two or more processes are waiting indefinitely for an event

that can be caused by only one of the waiting processes.

I Let S and Q be two semaphores initialized to 1.

35 / 46
Starvation

I Starvation: indefinite blocking.

36 / 46
Starvation

I Starvation: indefinite blocking.

I A process may never be removed from the semaphore queue in which it

is suspended.

36 / 46
Starvation

I Starvation: indefinite blocking.

I A process may never be removed from the semaphore queue in which it

is suspended.

I If we remove processes from the list associated with a semaphore in LIFO

(last-in, first-out) order.

36 / 46
37 / 46
POSIX Semaphore

I sem open() creates a new semaphore or opens an existing one.

sem_t *sem_open(const char * name , int oflag , ...);

38 / 46
POSIX Semaphore

I sem open() creates a new semaphore or opens an existing one.

sem_t *sem_open(const char * name , int oflag , ...);

I sem wait() decrements the value of the semaphore.

int sem_wait(sem_t *sem);

38 / 46
POSIX Semaphore

I sem open() creates a new semaphore or opens an existing one.

sem_t *sem_open(const char * name , int oflag , ...);

I sem wait() decrements the value of the semaphore.

int sem_wait(sem_t *sem);

I sem post() increments the value of the semaphore.

int sem_post(sem_t *sem);

38 / 46
Parent-Child Example

void parent() {
sem_t *sem_id = sem_open(sem_name, O_CREAT, 0600, 0);

// The parent waits for its child to print

sem_wait(sem_id);
printf("Parent: Child Printed!\n");
sem_close(sem_id);
sem_unlink(sem_name);
}

39 / 46
Parent-Child Example

void parent() {
sem_t *sem_id = sem_open(sem_name, O_CREAT, 0600, 0);

// The parent waits for its child to print

sem_wait(sem_id);
printf("Parent: Child Printed!\n");
sem_close(sem_id);
sem_unlink(sem_name);
}

void child() {
sem_t *sem_id = sem_open(sem_name, O_CREAT, 0600, 0);

printf("Child: Hello parent!\n");

sem_post(sem_id);
}

39 / 46
Readers and Writers Problem

40 / 46
Readers and Writers Problem (1/3)

I A shared data set among a number of concurrent processes:

• Readers: only read the data set; they do not perform any updates.
• Writers: can both read and write.

41 / 46
Readers and Writers Problem (1/3)

I A shared data set among a number of concurrent processes:

• Readers: only read the data set; they do not perform any updates.
• Writers: can both read and write.

I Problem: allow multiple readers to read at the same time, only one single
writer can access the shared data at the same time.

41 / 46
Readers and Writers Problem (1/3)

I A shared data set among a number of concurrent processes:

• Readers: only read the data set; they do not perform any updates.
• Writers: can both read and write.

I Problem: allow multiple readers to read at the same time, only one single
writer can access the shared data at the same time.

I Shared Data
• Semaphore rw mutex initialized to 1.
• Semaphore mutex initialized to 1.
• Integer read count initialized to 0.

41 / 46
Readers and Writers Problem (2/3)

I The writer process.

do {
wait(rw_mutex);
...
/* writing is performed */
...
signal(rw_mutex);
} while (true);

42 / 46
Readers and Writers Problem (3/3)

I The reader process.

do {
wait(mutex);
read_count++;
if (read_count == 1)
wait(rw_mutex);
signal(mutex);
...
/* reading is performed */
...
wait(mutex);
read_count--;
if (read_count == 0)
signal(rw_mutex);
signal(mutex);
} while (true);

43 / 46
Summary

44 / 46
Summary

I Access to shared data

45 / 46
Summary

I Access to shared data

I The critical-section problem

45 / 46
Summary

I Access to shared data

I The critical-section problem

I Requirements: mutual-exclusion, progress, bounding waiting

45 / 46
Summary

I Access to shared data

I The critical-section problem

I Requirements: mutual-exclusion, progress, bounding waiting

I CS solutions:
• Peterson solution, mutex lock, semaphore

45 / 46
Summary

I Access to shared data

I The critical-section problem

I Requirements: mutual-exclusion, progress, bounding waiting

I CS solutions:
• Peterson solution, mutex lock, semaphore

I Reader/writer problem

45 / 46
 Questions?
Acknowledgements
Some slides were derived from Avi Silberschatz slides.

46 / 46