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

Concurrent Systems/notes/5 - Software Transactional Memory.md

@@ -3,4 +3,24 @@
 - 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.
-	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