vault backup: 2025-03-03 09:17:47
This commit is contained in:
parent
47c1a1181e
commit
38bc756787
1 changed files with 17 additions and 1 deletions
|
@ -61,7 +61,7 @@ While `read()` and `write()` may be considered as atomic, their sequential compo
|
|||
|
||||
![[Pasted image 20250303090135.png]]
|
||||
|
||||
#### Mutual Exclusion (MUTEX)
|
||||
### Mutual Exclusion (MUTEX)
|
||||
Ensure that some parts of the code are executed as *atomic*.
|
||||
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*).
|
||||
|
||||
#### 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
|
Loading…
Reference in a new issue