diff --git a/.obsidian/workspace.json b/.obsidian/workspace.json index b10351f..8b81bd4 100644 --- a/.obsidian/workspace.json +++ b/.obsidian/workspace.json @@ -38,7 +38,7 @@ "file": "Concurrent Systems/slides/class 6.pdf", "page": 9, "left": -23, - "top": 594, + "top": 475, "zoom": 0.6805225653206651 }, "icon": "lucide-file-text", diff --git a/Concurrent Systems/notes/6a - Alternatives to Atomicity.md b/Concurrent Systems/notes/6a - Alternatives to Atomicity.md index 3643197..6656723 100644 --- a/Concurrent Systems/notes/6a - Alternatives to Atomicity.md +++ b/Concurrent Systems/notes/6a - Alternatives to Atomicity.md @@ -1,5 +1,6 @@ Let us define $op ->_{proc} op'$ to hold whenever there exists a process p that issues both operations with `res[op]` happening before `inv[op']`. +### Sequential consistency **Def:** a complete history is sequentially consistent if there exists a sequential history $𝑆$ s.t. ![[Pasted image 20250324082534.png]] @@ -17,4 +18,17 @@ In isolation, both processes are sequentially consistent. However, no total order on the previous 6 operations respects the semantics of a queue: - if p1 receives b' from Q'.deq, we have that Q'.enq(a'), must arrive after Q'.enq(b') - - to respect $\to_{proc}$ \ No newline at end of file + - to respect $\to_{proc}$, also the remaining behavior of p2 must arrive after + - hence, Q.enq(a) arrived before Q.enq(b) and so it is not possible for p2 to receive b from its Q.deq. + +Hence, we have two histories that are sequentially consistent but whose composition cannot be sequentially consistent $\to$ **no compositionality!** + +### Serializability +(typical notion in databases) + +- instead of processes, we have transactions +- consequently, we have also two other kinds of events: `abort(t)` and `commit(t)` + - in every history, we have at most one of these events for every transaction + - if the history is complete, we must have exactly one of these events for transaction +- a sequential history is formed by committed transactions only +