I did a test of Intel'sSTM using a test program I have used to experiment with multi-threading technology.
I was pretty impressed; Intel's STM handily outperforms our internal transactionalmulti-threadings support (which you could call STO, where O stands for Objects). In the test example, it also outperforms using explicit locks (which have to be applied very carefully to avoid deadlock).
As you would expect, there are a whole range of issues in using this apporach inside the product I work on (e.g. changing compiler would be a 'big deal'). But the big things I need to ask about are...
a. Support for allocating and freeing memory inside transactions. The sort of things we want to multi-thread do lots of memory allocations. Because alloc / free needs to transact, this is non-trivial (i.e. if something frees up memory, and the transaction is aborted, the memory has to become re-allocated at the same address).
b.For the approach to be useable inside out product, the transaction system would have to become more open. There are parts of our system that we probably could never change how they transact. So if an abort occurred, we would have to tell these components to abort what they have done (they have facilities to control how they transact, so we just need a way to hooking STM into these facilities).
c. Probably, we would needmore control over individual decisions and policies. We have objects that vary in the required amount of protectiondepending on how they are being used. In some cases, fine grained locking (such as STM provides) is needed. On other cases, the locking is much coarser (it is essentially per document). This decision is a run time decision, not a decision we can make when writing the code.
Points b. and c. are really about openness and us being able to participate in the STM processing, rather than just have Intel do everything
Anyway, we are very interested in how this all evolves and any feedback is appreciated.