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]]
	*p1 is starving!*
$$\text{Starvation freedom} \not \implies \text{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).