vault backup: 2025-03-10 16:50:21
This commit is contained in:
parent
44a201686b
commit
131672231a
2 changed files with 4 additions and 3 deletions
4
.obsidian/workspace.json
vendored
4
.obsidian/workspace.json
vendored
|
@ -34,9 +34,9 @@
|
|||
"type": "pdf",
|
||||
"state": {
|
||||
"file": "Concurrent Systems/slides/class 3.pdf",
|
||||
"page": 8,
|
||||
"page": 9,
|
||||
"left": -26,
|
||||
"top": 376,
|
||||
"top": 381,
|
||||
"zoom": 0.57541567695962
|
||||
},
|
||||
"icon": "lucide-file-text",
|
||||
|
|
|
@ -165,7 +165,8 @@ W.r.t. the execution of $p_j$, it can be that
|
|||
- this read overlaps with `FLAG[j] <- up` by Lemma 1, `MY_TURN[i] < MY_TURN[j]` and ok
|
||||
- this read is contained within the computation of `MY_TURN[j]`, but it's not possible, since `MY_TURN` is computed with the `FLAG` up
|
||||
- this read overlaps with `FLAG[j] <- down` or this read happens when $p_j$ is in the bakery:
|
||||
- `MY_TURN[j] has been ...
|
||||
- `MY_TURN[j]` has been decided and no write will change it until $p_j$ is in the bakery, and `MY_TURN[j] > 0` of course
|
||||
- When $p_i$ evaluated the second wait for j, it found out that $⟨MY_TURN[i],i⟩ < ⟨MY_TURN[j],j⟩$, good!
|
||||
continuare
|
||||
|
||||
**MUTEX:** $p_i$ and $p_j$ cannot simultaneously be in the CS:
|
||||
|
|
Loading…
Reference in a new issue