master-degree-notes/Concurrent Systems/notes/1 - CS Basics.md

#### Definizioni di base
- A **sequential algorithm** is the formal description of the behavior of an *abstract* state machine.
- A **program** is a sequential algorithm written in a programming language.
- A **process** is a program executed on a *concrete* machine, characterized by its *state* (e.g. values of the registers).
- If the process follows one single control flow (i.e. one program counter) then it is a **sequential process**, or **thread**.
- A set of sequential state machines that run simultaneously and interact through shared memory through a *shared medium* is called **concurrency**.

>[!note]
*"In a concurrent system there must be something shared"*

#### Advantages of concurrent systems
- efficiency: can run different stuff in parallel
- simplification of the logic by dividing the task in simpler tasks, running them in different processes and combining the results together.

#### Features of a concurrent system
We can assume many features:
- Reliable vs Unreliable
- Synchronous vs Asynchronous
- Shared memory vs Channel-based communication

- **Reliable** system: every process correctly executes its program.
- **Asynchronous:** no timing assumption (every process has its own clock, which are independent one from the other).
- **Shared medium:** A way is through a shared memory area, another way is through message passing.

>[!info] For this part of the course we assume that every process has a local memory but can access a shared part of the memory. We will assume that memory is split into registers (will see later).

**For now, we will assume that processes won't fail.**
We also assume that we have one processor per process. But actually the processor can be a shared resource (more processes than processors).

### Synchronization: cooperation vs competition
Definition of **synchronization:** the behavior of one process depends on the behavior of others.

This requires two fundamentals interactions:
- **Cooperation**
- **Competition**

#### Cooperation
Different processes work to let all of them succeed in their task.

1. **Rendezvous:** every involved process has a control point that can be passed only when all processes are at their control point: the set of all control points is called *barrier*.
2. **Producer-consumer:** two kind of processes, one that produces data and one that consumes them
	- only produced data can be consumed
	- every datum can be consumed at most once

>[!example] London Trip example
>You want to organize a trip to London with your friends and you decide to divide the tasks: one of your friends will buy the tickets, another one will book the hotel, and another one will plan the museum to visit. After all of them completed the assigned task, you can go.
#### Competition
Different processes aim at executing some action, but only one of them succeeds.
Usually, this is related to the access of the same shared resource.

Example: two processes want to withdraw from a bank account.

```js
function withdraw() {
	x := account.read();
	if x ≥ 1M€ {
		account.write(x – 1M€);
	}
}
```

While `read()` and `write()` may be considered as atomic, their sequential composition **is not**.

![[Pasted image 20250303090135.png]]

#### Mutual Exclusion (MUTEX)
Ensure that some parts of the code are executed as *atomic*.
>[!warning] 
>MUTEX is needed **both** in competition and in cooperation [[### Synchronization: cooperation vs competition|synchronization]].

Of course, MUTEX is required only when accessing shared data.

>[!def] Critical Section
*(henceforth referred to as CS)* A set of code parts that must be run without interferences, i.e. when a process is in a certain shared object (CS) than no other process is on that CS.


##### MUTEX problem
We need to design an entry protocol (lock) and an exit protocol (unlock) such that, when used to encapsulate a CS (for a given shared object), **ensure that at most one process at a time is in a CS** (for that shared object).

*We assume that all CSs terminate and that the code is well-formed (lock ; critical section ; unlock).*

#### Safety and liveness
Every solution to a problem should satisfy at least:
- **Safety**: *nothing bad ever happens*
- **Liveness:** *something good eventually happens* (eventually = prima o poi, ma con la certezza che prima o poi succederà)

***Liveness without safety:*** allow anything, something good may eventually happen but also something terrible!

***Safety without liveness:*** forbid anything (no activity in the system)

>[!warning] So safety is necessary for correctness, liveness for meaningfulness.

##### In the context of MUTEX:
- **Safety:** there is at most one process at a time in a CS (*mutual exclusion*).
- **Liveness:**
	- **Deadlock freedom:** if there is at least one invocation of `lock`, one process will eventually enter the critical section. This means that **the system is not blocked forever**.
	- **Starvation freedom:** every invocation of lock eventually grants access to the associated CS (a process won't be stuck forever while other processes are racing for the CS).
	- **Bounded bypass:** like starvation freedom, but stronger! We define an upper bound on the number of failures. Let $n$ be the number of processes; then, there exists $f: N \to N$ s.t. every lock enters the C.S. after at most $f(n)$ other CSs (The process must enter the CS in at most $f(n)$ steps).

**Both inclusions are strict:**
$$\text{Deadlock freedom} \not \implies \text{Starvation freedom}$$
	![[Pasted image 20250303093116.png]]

Starvation freedom $\not \implies$ Bounded bypass
	Assume a $f$ and consider the scheduling above, where p2 wins $f(3)$ times and so does p3, then p1 looses (at least) $2f(3)$ times before winning.

### Atomic R/W registers
We will consider different computational models according to the available level of atomicity of the operations provided.

Atomic R/W registers are storage units that can be accessed through two operations (READ and WRITE) such that
1. Each invocation of an operation
	- locks instantaneous (it can be depicted as a single point on the timeline: there exist $t : OpInv \to R+$)
	- may be located in any point between its starting and ending time
	- does not happen together with any other operation ($t$ is injective)
2. Every READ returns the closest preceding value written in the register, or the initial value (if no WRITE has occurred).

### Peterson algorithm (for two processes)
Let's try to enforce MUTEX with just 2 processes.

##### 1st attempt:
```
lock(i) :=
	AFTER_YOU <- i
	wait AFTER_YOU != i
	return

unlock(i) :=
	return
```
This protocol satisfies MUTEX, but suffers from deadlock (if one process never locks).

##### 2nd attempt:
```
Initialize FLAG[0] and FLAG[1] to down
lock(i) :=
	FLAG[i] <- up
	wait FLAG[1-i] = down
	return

unlock(i) :=
	FLAG[i] <- down
	return
```
Still suffers from deadlock if both processes simultaneously raise their flag.

##### Correct solution:
```
Initialize FLAG[0] and FLAG[1] to down
lock(i) :=
	FLAG[i] <- up
	AFTER_YOU <- i
	wait FLAG[1-i] = down OR AFTER_YOU != i
	return

unlock(i) :=
	FLAG[i] <- down
	return
```

**Features:**
- it satisfies MUTEX
- it satisfies bounded bypass, with bound = 1
- it requires 2 one-bit SRSW registers (the flags and 1 one-bit MRMW registers (AFTER_YOU)
- Each lock-unlock requires 5 accesses to the registers (4 for lock and 1 for unlock)

##### MUTEX proof
Assume p0 and p1 are simultaneously in the CS.

How has p0 entered its CS?
a) `FLAG[1] = down`, this is possible only with the following interleaving:
![[Pasted image 20250303100721.png]]

b) `AFTER_YOU = 1`, this is possible only with the following interleaving:
![[Pasted image 20250303100953.png]]

##### Bounded Bypass proof (with bound = 1)
- If the wait condition is true, then it wins (and waits 0).

- Otherwise, it must be that `FLAG[1] = UP` **AND** `AFTER_YOU = 0` (quindi p1 ha invocato il lock e p0 dovrà aspettare).

- If p1 never locks anymore then p0 will eventually read `F[1]` and win (waiting 1).

- It is possible tho that p1 locks again:
	- if p0 reads `F[1]` before p1 locks, then p0 wins (waiting 1)
	- otherwise p1 sets A_Y to 1 and suspends in its wait (`F[0] = up AND A_Y = 1`), p0 will eventually read `F[1]` and win (waiting 1).

### Peterson algorithm ($n$ processes)
- FLAG now has $n$ levels (from 0 to n-1)
	- level 0 means down
	- level >0 means involved in the lock
- Every level has its own AFTER_YOU

```
Initialize FLAG[i] to 0, for all i

lock(i) :=
	for lev = 1 to n-1 do
		FLAG[i] <- lev
		AFTER_YOU[lev] <- i
		wait (∀k!=i, FLAG[k] < lev
			OR AFTER_YOU[lev] != i)
	return

unlock(i) :=
	FLAG[i] <- 0
	return
```
We say that pi is at level h when it exits from the h-th wait -> a process at level h is at any level <= h

##### MUTEX proof
Lemma: for every $ℓ \in \{0,\dots,n-1\}$ , at most n-ℓ processes are at level ℓ, this implies MUTEX by taking ℓ = n-1

Proof by induction on ℓ

Base (ℓ=0): trivial

Induction (true for ℓ, to be proved for ℓ+1):
- p at level ℓ can increase its level by writing its FLAG at ℓ+1 and its index in $A_Y[ℓ+1]$
- let $p_x$ be the last one that writes `A_Y[ℓ+1]`, so `A_Y[ℓ+1]=x`
- for $p_x$ to pass at level ℓ+1, it must be that $∀k≠x. F[k] < ℓ+1$, then $p_x$ is the only proc at level ℓ+1 and the thesis holds, since 1<=n-ℓ-1
- otherwise, $p_x$ is blocked in the wait and so we have at most n-ℓ-1 processes at level ℓ+1: those at level ℓ, that by induction are at most n-ℓ, except for px that is blocked in its wait.

##### Starvation freedom proof
**Lemma:** every process at level ℓ ($\leq n-1$) eventually wins $\to$ starvation freedom holds by taking $ℓ=0$.

Reverse induction on ℓ
Base ($ℓ=n-1$): trivial

Induction (true for ℓ+1, to be proved for ℓ):
- Assume a $p_x$ blocked at level ℓ (aka blocked in its ℓ+1-th wait) $\to \exists k\neq x, F[k]\geqℓ+1 \land A\_Y[ℓ+1]=x$

- If some $p_{y}$ will eventually set $A\_Y[ℓ+1]$ to $y$, then $p_x$ will eventually exit from its wait and pass to level ℓ+1

- Otherwise, let $G = \{p_{i}: F[i] \geq ℓ+1\}$ and $L=\{p_{i}:F[i]<ℓ+1\}$
	- if $p \in L$, it will never enter its ℓ+1-th loop (as it would write $A_Y[ℓ+1]$ and it will unblock $p_x$, but we are assuming that it is blocked)
	- all $p \in G$ will eventually win (by induction) and move to L
		- $\to$ eventually, $p_{x}$ will be the only one in its ℓ+1-th loop, with all the other processes at level <ℓ+1
		- $\to$ $p_{x}$ will eventually pass to level ℓ+1 and win (by induction)


##### Peterson algorithm cost
- $n$ MRSW registers of $\lceil \log_{2} n\rceil$ bits (FLAG)
- $n-1$ MRMW registers of $\lceil \log_{2}n \rceil$ bits (AFTER_YOU)
- $(n-1)\times(n+2)$ accesses for locking and 1 access for unlocking

It satisfies MUTEX and starvation freedom. It does not satisfy bounded bypass:
- consider 3 processes, one sleeping in its first wait, the others alternating in the CS
- when the first process wakes up, it can pass to level 2 and eventually win
- but the sleep can be arbitrary long and in the meanwhile the other two processes may have entered an unbounded number of CSs

Easy to generalize to k-MUTEX.