1

I am trying to understand TM. I have read Ben's answer here and tried to understand some other articles on the Internet. I am still not quite sure if I understood correctly though. In my understanding in transactional memory the threads may execute the transactions in parallel. If two (or more) threads try to access the same transaction variable, all threads except one will abort the transaction and start over (at some point, not necessarily immediately). The one that doesn't abort updates the transaction variable.

So in a nutshell in TM all threads run in parallel and we hope that there won't be any access overlaps to transactional variables and if there are, we just only let one thread continue, while the others roll back and retry. Is this understanding of TM correct?

timtam
  • 220
  • 2
  • 9

1 Answers1

1

That is a pretty good synopsis. The details are quite convoluted, and it is possible that some transactions cannot be expressed in a given TM monitor; which means that you may have to include two implementations of your transaction - an optimistic and pessimistic one.

The cache is the underlying implementation; when you make a transactional reference to memory, the cache notes this, and either generates an alarm (restart) when any of those references are modified, or rejects the transaction close if any have been modified.

The number of transactional variables may have to, in general, be lower than your cache's associativity; otherwise they would evict one another from the cache, resulting in a transaction that could never complete.

How interrupts function in the midst of a transaction remains an open problem.

In short, it was a bit of a fascinating idea 20 years ago. As it nears general usability, it seems to have rapidly expanding hardware requirements. It may be more useful for warming cold climes than accelerating computer systems.

mevets
  • 10,070
  • 1
  • 21
  • 33