One nuance I came across when reading about transactional memory is that composing them isn't as simple as it might seem. For instance, let's say that there is a transaction B nested within transaction A. Even if B is complete and ready to commit without conflicts, it can't actually do so unless all of A is complete and ready to commit without conflicts! Thus, there is additional logic that needs to be implemented in software/hardware to handle nested transactions.

@kevtan Do you think there are any issues with keeping memory consistency in this case? That is, if A reads from an address that B wants to commit. Or was this additional logic in the form of "forwarding" the to-be-committed values to A to preserve consistency within the composed transaction.

@l-henken I would guess that the nested transaction B could probably write to the same undo log or write buffer as A, but B would still see changes A made before B started, and A would still see changes B made after B finishes.

One example I found of the additional logic to handle nested transactions is to maintain the current depth of the nested transaction, incrementing a counter every time a transaction begins and decrementing every time a transaction finishes. Then, you only commit all the changes when the counter hits 0 on a decrement.

I'm interested if the implementation chooses to use interleaved scheduling of two transactions, it might have to build up a dependency graph to assure there is no deadlock.