vault backup: 2025-03-03 09:17:47

This commit is contained in:
Marco Realacci 2025-03-03 09:17:47 +01:00
parent 47c1a1181e
commit 38bc756787

View file

@ -61,7 +61,7 @@ While `read()` and `write()` may be considered as atomic, their sequential compo
![[Pasted image 20250303090135.png]] ![[Pasted image 20250303090135.png]]
#### Mutual Exclusion (MUTEX) ### Mutual Exclusion (MUTEX)
Ensure that some parts of the code are executed as *atomic*. Ensure that some parts of the code are executed as *atomic*.
This is needed in competition but also in cooperation. This is needed in competition but also in cooperation.
@ -75,3 +75,19 @@ Design an entry protocol (lock) and an exit protocol (unlock) such that, when us
We assume that all C.S.s terminate and that the code is well-formed (*lock ; critical section ; unlock*). We assume that all C.S.s 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 without safety:* allow anything, something good may eventually happen but also something terrible!
*Safety without liveness:* forbid anything (no activity in the system)
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.
- **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 eve