vault backup: 2025-03-10 10:35:13

This commit is contained in:
Marco Realacci 2025-03-10 10:35:13 +01:00
parent a3b68aeb4a
commit a03d441faa
2 changed files with 22 additions and 4 deletions

View file

@ -34,9 +34,9 @@
"type": "pdf", "type": "pdf",
"state": { "state": {
"file": "Concurrent Systems/slides/class 3.pdf", "file": "Concurrent Systems/slides/class 3.pdf",
"page": 13, "page": 14,
"left": -26, "left": -26,
"top": 182, "top": 41,
"zoom": 0.57541567695962 "zoom": 0.57541567695962
}, },
"icon": "lucide-file-text", "icon": "lucide-file-text",

View file

@ -226,6 +226,24 @@ unlock(i) :=
#### MUTEX proof #### MUTEX proof
**Theorem:** if $p_i$ is in the CS, then $p_j$ cannot simultaneously be in the CS. **Theorem:** if $p_i$ is in the CS, then $p_j$ cannot simultaneously be in the CS.
*Proof:* by contradiction. a *Proof:* by contradiction.
#### proof ...
#### Bounded bypass proof
**Lemma 1:** exactly after n CSs there is a reset of DATE.
*Proof:*
- the first CS leads $max_j{DATE[j]}$ to n+1
- the seconds CS leads ... to n+2
- ...
- the n-th read leads ... to n+n = 2n -> RESET
**Lemma 2:** there can be at most one reset of DATE during an invocation of a lock
*Proof:*
- let $p_i$ invoke lock, if no reset occurs, ok
- otherwise, let us consider the moment in which a reset occurs
- if pi is the next process that enters the CS, ok
- Otherwise let $p_j$ be the process that enters, its next date is $n+1 > DATE[i]$
- $p_{j}$ cannot surpass $p_i$ again (before a RESET)
- The worst case is then all processes perform lock together and $i = n$ (i am process n)
- all $p_{1}\dots p_{n}$ surpass $