marcorealacci/master-degree-notes
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

vault backup: 2025-03-08 17:41:57

Browse source
This commit is contained in:
Marco Realacci 2025-03-08 17:41:57 +01:00
parent 647ba29219
commit 8efa7b29fa
1 changed files with 10 additions and 9 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

19
Concurrent Systems/notes/1 - CS Basics.md
View file

@ -72,26 +72,27 @@ Ensure that some parts of the code are executed as *atomic*.
Of course, MUTEX is required only when accessing shared data.
>[!def] Critical Section
A set of code parts that must be run without interferences, i.e. when a process is in a certain shared object (C.S.) than no other process is on that C.S..
*(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
Design an entry protocol (lock) and an exit protocol (unlock) such that, when used to encapsulate a C.S. (for a given shared object), ensure that at most one process at a time is in a C.S. (for that shared object).
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 C.S.s terminate and that the code is well-formed (*lock ; critical section ; unlock*).
*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*
- **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!
***Liveness without safety:*** allow anything, something good may eventually happen but also something terrible!
*Safety without liveness:* forbid anything (no activity in the system)
***Safety without liveness:*** forbid anything (no activity in the system)
So safety is necessary for correctness, liveness for meaningfulness.
>[!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 C.S.
##### In the context of MUTEX:
- **Safety:** there is at most one process at a time in a CS.
- **Liveness:**
- **Deadlock freedom:** if there is at least one invocation of lock, eventually after at least one process enters a C.S.
- **Starvation freedom:** every invocation of lock eventually grants access to the associated C.S.