A good way I've found for understanding transactional programs is to imagine a simple piece of atomic code. At its core an atomic operation can take as many steps as are necessary in practice, so long as for our purposes and at our layer of abstraction it appears as one complete step. Then, if we just scale this idea up and consider more complex operations, such as completing a bank transfer, which need the same atomic guarantees we can see simply how a transactional program should work.
Is the idea of Transactional Memory basically that the memory itself will check if there is a conflict of read and writing?
System fetch the atomic code, then the Transactional Memory checks if the code contains variables pointing to memory that is in conflict, if not, it execute the code as a whole and block other threads that might access the same memory address. And with this, we no longer need to add lock from developer's perspective.
Is this the correct way of understanding?
Please log in to leave a comment.
The consistency model for TM is sequential consistency. Units of execution are not individual loads and stores but actually are transactions.