marcorealacci/master-degree-notes
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

vault backup: 2025-03-17 10:29:23

Browse source
This commit is contained in:
Marco Realacci 2025-03-17 10:29:23 +01:00
parent 9772a79c93
commit 483a72be5c
2 changed files with 23 additions and 3 deletions
Download patch file Download diff file Expand all files Collapse all files

4
.obsidian/workspace.json vendored
View file

@ -34,9 +34,9 @@
"type": "pdf", "type": "pdf",
"state": { "state": {
"file": "Concurrent Systems/slides/class 5.pdf", "file": "Concurrent Systems/slides/class 5.pdf",
"page": 1, "page": 2,
"left": -27, "left": -27,
"top": 10, "top": 266,
"zoom": 0.5754156769596199 "zoom": 0.5754156769596199
}, },
"icon": "lucide-file-text", "icon": "lucide-file-text",

22
Concurrent Systems/notes/5 - Software Transactional Memory.md
View file

@ -3,4 +3,24 @@
- Differently from transactions in databases, the code can be any code, not just queries on the DB - Differently from transactions in databases, the code can be any code, not just queries on the DB
**Transaction:** an atomic unit of computation (look like instantaneous and without overlap with any other transaction), that can access atomic objects. **Transaction:** an atomic unit of computation (look like instantaneous and without overlap with any other transaction), that can access atomic objects.
when executed alone, every transaction success when executed alone, every transaction successfully terminates.
**Program:** set of sequential processes, each alternating transactional and non-transactional code
**STM system:** online algorithm that has to ensure the atomic execution of the transactional code of the program.
To guarantee efficiency, all transactions can be executed at the same time (optimistic execution approach), but they must be totally ordered
- not always possible (where there are different accesses to the same object, with at least one of them that changes it)
- commit/abort transactions at their completion point (or even before)
- in case of abort, either try to re-execute or notify the invoking proc.
- possibility of unbounded delay
Conceptually, a transaction is composed of 3 parts:
`[READ of atomic reg’s] [local comput.] [WRITE into shared memory]`
The key issue is ensuring consistency of the shared memory
- as soon as some inconsistencies is discovered, the transaction is aborted
Implementation: every transaction uses a local working space
- For every shared register: the first READ copies the value of the reg. in the local copy; successive READs will then read from the local copy
- Every WRITE modifies the local copy and puts the final