diff --git a/.obsidian/workspace.json b/.obsidian/workspace.json
index 40dca75..e9c0119 100644
--- a/.obsidian/workspace.json
+++ b/.obsidian/workspace.json
@@ -34,9 +34,9 @@
               "type": "pdf",
               "state": {
                 "file": "Concurrent Systems/slides/class 5.pdf",
-                "page": 1,
+                "page": 2,
                 "left": -27,
-                "top": 10,
+                "top": 266,
                 "zoom": 0.5754156769596199
               },
               "icon": "lucide-file-text",
diff --git a/Concurrent Systems/notes/5 - Software Transactional Memory.md b/Concurrent Systems/notes/5 - Software Transactional Memory.md
index 42d8ad1..5213517 100644
--- a/Concurrent Systems/notes/5 - Software Transactional Memory.md	
+++ b/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
\ No newline at end of file
+	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
\ No newline at end of file