1. Happy Children’s Day

2. Process Synchronization05
Process Synchronization
In today’s lecture session, we’ll be covering process synchronization.
Kai Bu

3. Process Synchronization
cooperating processes?
for which
Which processes do you think need to be synchronized?
Still remember the two types of processes: independent, cooperating

4. Process Synchronization
cooperating processes:
can affect or be affect by other procs via shared data
It’ll be the cooperating processes that need to be well synchronized,
as they can affect or be affected by other processes executing in the system.

5. Process Synchronization
for what?
Then why should cooperating processes be synchronized

6. Process Synchronization
for what：
data consistency
Because if they are not synchronized,
concurrent access to shared data may result in data inconsistency.

7. Data Inconsistency producer process
while (true) { /* produce an item in next produced */
while (counter == BUFFER_SIZE) ;
/* do nothing */
buffer[in] = next_produced;
in = (in + 1) % BUFFER_SIZE;
counter++; }
producer process
Now let’s use an example to demonstrate when will data inconsistency occur.
In this example, we consider a producer-consumer model where the producer generates one new data item after another, and adds it to a shared buffer.
Then the consumer can fetch a data item from the buffer and consumes it.
Apparently, each time a new data item is generated and added, the number (denoted as counter) of data items in the buffer should be incremented.

8. Data Inconsistency producer process consumer process
while (true) { /* produce an item in next produced */
while (counter == BUFFER_SIZE) ;
/* do nothing */
buffer[in] = next_produced;
in = (in + 1) % BUFFER_SIZE;
counter++; }
producer process
consumer process
In contrast, each time a data item is fetched and consumed by the consumer, the number (denoted as counter) of data items in the buffer should be decremented.
while (true) {
while (counter == 0)
; /* do nothing */
next_consumed = buffer[out];
out = (out + 1) % BUFFER_SIZE;
counter--;
/* consume the item in next consumed */ }

9. Data Inconsistency producer process consumer process
while (true) { /* produce an item in next produced */
while (counter == BUFFER_SIZE) ;
/* do nothing */
buffer[in] = next_produced;
in = (in + 1) % BUFFER_SIZE;
counter++; }
producer process
consumer process
Clearly, counter in this example is a shared data item.
Only when the producer and the consumer updates counter in a correct order can the result be correct.
while (true) {
while (counter == 0)
; /* do nothing */
next_consumed = buffer[out];
out = (out + 1) % BUFFER_SIZE;
counter--;
/* consume the item in next consumed */ }

10. Data Inconsistency example: current counter = 5
two concurrent producer and consumer processes
expectant: updated counter = 5
while (true) { /* produce an item in next produced */
while (counter == BUFFER_SIZE) ;
/* do nothing */
buffer[in] = next_produced;
in = (in + 1) % BUFFER_SIZE;
counter++; }
producer process
consumer process
For example, when the current value of counter = 5;
We have two concurrent producer and consumer processes running,
That is, the producer is incrementing counter while the consumer is decrementing it;
for the correct value of counter after both updates, it should stay the same, which is 5, right?
while (true) {
while (counter == 0)
; /* do nothing */
next_consumed = buffer[out];
out = (out + 1) % BUFFER_SIZE;
counter--;
/* consume the item in next consumed */ }

11. Data Inconsistency counter++ register1 = counter
register1 = register1 + 1
counter = register1
counter--
register2 = counter
register2 = register2 -1
counter = register2
More specifically, the increment and decrement of counter are implemented like this.
What we need to pay attention to here is that a single operation in the original code segment now involves more than one instruction.
And for all these instructions, CPU has to process them one by one, possibly in an interleaved fashion.

12. Data Inconsistency Possible interleaved execution: producer consumer
register1 = counter
register1 = register1 + 1
register2 = counter
register2 = register2 – 1
counter = register1
counter = register2

13. Data Inconsistency Possible interleaved execution: value producer
consumer
register1 = counter
register1 = register1 + 1
register2 = counter
register2 = register2 – 1
counter = register1
counter = register2 5 6 4

14. Data Inconsistency Possible interleaved execution: value producer
consumer
register1 = counter
register1 = register1 + 1
register2 = counter
register2 = register2 – 1
counter = register1
counter = register2 5 6 4
And this is when a data inconsistency occurs.
which should be 5

15. Race Condition
Several processes access and manipulate the same data concurrently
The outcome of the execution depends on the particular access order
value
producer
consumer
register1 = counter
register1 = register1 + 1
register2 = counter
register2 = register2 – 1
counter = register1
counter = register2 5 6 4
Data consistency is caused by race condition,
a situation in which several processes access and manipulate the same data concurrently,
And the outcome of the execution depends on the particular order in which the access takes place.
which should be 5

16. Process Synchronization
a generalized model?
So, we need to tame race condition by synchronizing processes such that no inconsistency over shared data occurs.
Before investigating solutions, we first discuss how to model the synchronization problem.

17. The Critical-Section Problem
How to cooperate with n processes:
{P0, P1, …, Pn-1}
General structure of process Pi:
Usually, we model process synchronization as the critical-section problem.
In this model, we consider a system with n processes.
A process Pi has an important segment of code, called critical section,
In which the process may be changing common variables, updating a table, writing a file, and so on.
**critical section refers a code segment, so it is included in each process;
But the data operated by critical sections of processes are the same.
change common vars
update a table
write a file
etc.

18. The Critical-Section Problem
How to cooperate with n processes:
{P0, P1, …, Pn-1}
General structure of process Pi:
The critical section should be exclusive.
When one process is executing in its critical section, no other process is allowed to execute its critical section.
That is, no two processes are executing in their critical sections at the same time.
Based on this model, the goal of the critical-section problem is to design a protocol that the processes can use to cooperate.
exclusive
change common vars
update a table
write a file
etc.

19. The Critical-Section Problem
How to cooperate with n processes:
{P0, P1, …, Pn-1}
General structure of process Pi:
request permission to cs
Each process must request permission to enter its critical section.
The section of code implementing this request is the entry section.
exclusive
change common vars
update a table
write a file
etc.

20. The Critical-Section Problem
Three solution requirements:
Mutual exclusion
only one process can be executing in the critical section at the same time
Progress
selecting the next proc to enter its critical section cannot be postponed indefinitely
Bounded waiting
waiting time for a proc to enter its critical section cannot be indefinite
A solution to the critical-section problem must satisfy three requirements.
The first one is mutual exclusion: if process Pi is executing in its critical section, then no other processes can be executing in their critical sections.
The second one is progress: if no process is executing in its critical section and some processes wish to enter their critical sections, then only those processes that are not executing in their remainder sections can participate in deciding which will enter its critical section next, and this selection cannot be postponed indefinitely.
The third one is bounded waiting: there exists a bound, or limit, on the number of times that other processes are allowed to enter their critical selections after a process has made request to enter its critical section and before that request is granted.

21. Process Synchronization
how?
Now, let’s see how to synchronize multiple processes to solve the critical

22. Peterson’s Solution
P0 and P1 alternate execution between their critical and remainder sections
Also denoted as Pi and Pj with j = i-1
Share two data items:
int turn; allowing a proc to enter cs
boolean flag[2]; proc is ready
A classic software-based solution to the critical-section problem is Peterson’s solution.
It considers two processes that alternate execution between their critical sections and remainder sections.

23. Peterson’s Solution structure of process Pi
Then the solution defines the structure of process Pi like this
structure of process Pi

24. Peterson’s Solution KEY: Pi enters cs only when
Pj is not BOTH allowed AND ready
a key part for understanding this solution is this while loop.

25. Peterson’s Solution A software-based solution
Not guaranteed to work correctly on modern computer architectures with load and store instructions

26. Synchronization Hardware
test_and_set() instruction
atomical, uninterruptible run;
return the original value of para;
set the new value of para as true;
Atomically run of test_and_set() instruction:
If two test_and_set() instructions are executed simultaneously (each on a different CPU),
they will be executed sequentially in some arbitrary order.

27. Synchronization Hardware
test_and_set() based mutual-exclusion

28. Synchronization Hardware
compare_and_swap() instruction
atomical, uninterruptible run;
return the original value of para “value”;
swap new_value with the original value upon the original = “expected”;

29. Synchronization Hardware
compare_and_swap() based mutual-exclusion

30. Synchronization Hardware
test_and_set() based bounded-waiting mutual-exclusion

31. Mutex Lock Mutual Exclusion Lock Software-based solution
Acquire the lock before entering cs
Release the lock when it exits cs
aka spinlock: because a proc spins while being busy waiting for the lock to become available

32. Mutex Lock

33. Semaphore
An integer variable S that is accessed only through two standard atomic operations:
wait(), signal()

34. Semaphore Usage Counting semaphore range over an unrestricted domain
Binary semaphore
range only between 0 and 1;
can be used to as mutex locks to provide mutual exclusion;

35. Semaphore Usage Counting semaphore
access to a given resource consisting of a finite number of instances;
initialize semaphore to no. of instances;
call wait() to use an instance;
call signal() to release an instance;
block if semaphore = 0;
Counting semaphores can be used to access to a given resource consisting of a finite number of instances.
The semaphore is initialized to the number of resources available.
Each process that wishes to use resource performs a wait() operation on the semaphore (thereby decrementing the count).
When a process releases a resource, it performs a signal() operation (incrementing the count).
When the count for the semaphore goes to 0, all resources are being used.
After that, processes that wish to use a resource will block until the count becomes greater than 0.

36. Semaphore Usage Binary semaphore two concurrent processes: P1 and P2;
P2’s statement S2 executes only after P1’s statement S1 has completed;
share a common semaphore synch, initialized as 0;
S1; wait(synch);
Signal(synch); S2;
we can also use semaphores to solve other synchronization problems.
For example, consider two concurrently running processes, P1 with a statement S1 and P2 with a statement S2.
Suppose we require that S2 be executed only after S1 has completed.
Sync solution using semaphore synch:

37. Semaphore Implementation
Adapt against busy waiting
New wait():
if semaphore is <= 0, proc blocks itself;
blocked proc joins a waiting queue associated with the semaphore, and switches to waiting state;
CPU scheduler takes over proc selection;

38. Semaphore Implementation
Adapt against busy waiting
New signal():
when another process executes signal(),
restart blocked proc by wakeup();
change it to ready state;
place it to ready queue.

39. Semaphore Implementation
Semaphore definition
list: when a process must wait on a semaphore, it is added to the list of processes
singal() removes one process from list and awakens that process

40. Semaphore Implementation

41. Semaphore Implementation
Deadlock
two or more procs are waiting indefinitely for an event that can be caused only by one of the waiting procs
1st run
2nd run

42. Semaphore Implementation
starvation
Deadlock causes indefinite blocking
two or more procs are waiting indefinitely for an event that can be caused only by one of the waiting procs
1st run
2nd run

43. Priority Inversion
A higher priority process is indirectly preempted by a lower priority one
Example: three processes with priorities
L(ow) < M(edium) < H(igh)
L is currently accessing resource R;
H waits for L to relinquish R;
M becomes runnable and preempt L;
Lower-priority M runs before higher-priority H

44. Priority Inversion Solution: Priority-Inheritance Protocol
all processes that are accessing resources needed by a higher-priority process inherit the higher priority until they are finished with the resources;
when they are finished, their priorities revert to their original values;

45. Priority Inversion Solution: Priority-Inheritance Protocol
Application to the previous example:
L is currently accessing resource R;
H requests R and waits for it from L;
L temporarily inherits H’s priority;
M becomes runnable;
L keeps running as its cur pri H > M;
L finishes and resumes to pri L;
between M & H, higher H is next to run;

46. Semaphore: Be Careful
careless usage causes deadlock

47. Process Synchronization
how to test?
Now we’ve covered the requirements for a satisfactory synchronization protocol,
We also investigated several ways to design one;
Besides the critical-section problem, are there any other models for us to test a synchronization protocol?

48. The Bounded-Buffer Problem
Shared data structures
int n; n buffers w/ each holding 1 item
semaphore mutex = 1;
semaphore empty = n;
semaphore full = 0;
One is called the bounded-buffer problem.
In this model, the producer and the consumer share a number n of buffers, each of which holds one data item;
The mutex semaphore provides mutual exclusion for accesses to the buffer pool and is initialized to the value 1.
The empty and full semaphores count the number of empty and full buffers.
The semaphore empty is initialized to the value n; the semaphore full is initialized to the value 0.

49. The Bounded-Buffer Problem
producer process

50. The Bounded-Buffer Problem
consumer process

51. The Readers-Writers Problem
Two types of processes share database
Readers: only read the database
Writers: update the database
Concurrent readers are harmless
Concurrent writer&reader OR writer&writer may cause chaos

52. The Readers-Writers Problem
The First Readers-Writers Problem
no reader be kept waiting unless a writer has already obtained permission to use the shared object;
no reader should wait for other readers to finish simply because a writer is waiting;
The Second Readers-Writers Problem
Once a writer is ready, that writer performs
its write as soon as possible
Two variants:
Regarding when to handle the newly coming writer while readers are reading the shared data object;

53. The Readers-Writers Problem
The First Readers-Writers Problem
no reader be kept waiting unless a writer has already obtained permission to use the shared object;
no reader should wait for other readers to finish simply because a writer is waiting;
The Second Readers-Writers Problem
Once a writer is ready, that writer performs
its write as soon as possible
writer starvation
But in both cases, either writers or readers may starve.
reader starvation

54. The Readers-Writers Problem
The First Readers-Writers Problem
starvation-able solution
shared data structures:
semaphore rw_mutex = 1;
semaphore mutex = 1;
int read_count = 0;
Now use the first readers-writers problem as an example, see how to design a starvation-free solution

55. The First Readers-Writers Problem starvation-able solution

56. The First Readers-Writers Problem starvation-able solution
allow writing only when no reading
reader

57. The Dining-Philosophers Problem
Circular table
One chopstick per philosopher
Need two chopsticks to eat
*some examples use forks

58. Ex: 5 Dining-Philosophers
Shared data:
semaphore chopstick[5]
*all initialized to 1
chopstick[i] is on the left of phil I
chopstick[i+1] is on the right of phil i

59. Ex: 5 Dining-Philosophers
Structure of philosopher i
no two neighbors
can eat simultaneously

60. Ex: 5 Dining-Philosophers
Structure of philosopher i
Although this solution guarantees that no two neighbors are eating simultaneously,
it nevertheless must be rejected because it could create a deadlock.
Suppose that all five philosophers become hungry at the same time and each grabs her left chopstick.
All the elements of chopstick will now be equal to 0.
When each philosopher tries to grab her right chopstick, she will be delayed forever
deadlock:
if all grabbed left chopstick

61. Deadlock-free Dining using Monitors
A philosopher may pick up her chopsticks only if both of them are available
Data structures:
delay pril i when she is hungry
but without both chopsticks
condition: monitor specific
condition.wait() makes the calling proc suspended
condition.signal() makes the suspended proc active

62. Monitor-based Deadlock-free Dining
phil i picks up both chopsticks
only when both neighbors are not eating

63. Monitor-based Deadlock-free Dining
phil i picks up both chopsticks
only when both neighbors are not eating
Philosophers must invoke pickup() and putdown() in the order of: pickup(), eat, then putdown()
to make sure that no two neighbors can eat simultaneously and there for achieve a deadlock-free solution to the dining-philosophers problem.
no two neighbors can eat simultaneously:
deadlock-free:

64. Review When is synchronization required? What is synchronization for?
How to synchronize?
When cooperating processes might be accessing shared data at the same time and different scheduling order may lead to different results;
Thus, need synchronization for guaranteeing data consistency. / to avoid data inconsistency, which is caused by race condition;

65. Chapter 5
The contents to be discussed can be found in chapters 3 and 4.

66. Assignment 1
Available: June 05, 2018
Due: June 21, 2018 on CourSys

67. ?

68. Thank
You

69. #What’s More
What Matters More Than Your Talents
by Jeff Bezos