26 lines
No EOL
1.7 KiB
Markdown
26 lines
No EOL
1.7 KiB
Markdown
- Group together parts of the code that must look like atomic, in a way that is transparent, scalable and easy-to-use for the programmer
|
||
- Differently from monitors, the part of the code to group is not part of the definition of the objects, but is application dependent
|
||
- 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 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 |