Log in

No account? Create an account

Previous Entry | Next Entry

Transactional Memory Everywhere?

I recently encountered a researcher who assured me that transactional memory (TM) would soon be the only synchronization mechanism, supplanting all the complex and error-prone synchronization mechanisms currently in use.  This did surprise me a bit, given that TM has some difficulty with commonplace operations such as input and output, but I most certainly cannot fault the man's ambitions for TM.  To his credit, he did acknowledge TM's difficulties with input and output.  Of course, there are a number of I/O scenarios that TM does quite well with, the prime example being buffered I/O, but other simple I/O scenarios such as remote procedure call appear to be problematic, at least at present.

However, anyone who has worked on a large software artifact will have encountered situations where the ability to do even very small and restricted transactions would be extremely helpful.  Even the relatively slow software TM (STM) implementations could do well in such situations, as the competing deadlock-avoidance/recovery schemes can be quite complex and slow in and of themselves.

That said, if TM is to achieve the researcher's great ambitions, it will need to interact with other mechanisms, be they I/O, system calls, or other synchronization primitives, with this latter being critically important when converting legacy software to TM.  To this end, this series of posts will look at challenges to TM posed by other mechanisms, along with alternative resolutions to these challenges.