I didn't see too many drawbacks to TM. Are there any serious ones?
oulgen
I believe that transactional memory requires you to do MUCH more during the compilation process if you're using a software based version. This requires a lot of overhead in your computation. Also, as far as I know, there isn't a very good version of transactional memory which makes the least amount of atomic operations. If you look at http://web.cse.ohio-state.edu/~agrawal/788-su08/Papers/week4/design_tradeoffs_modern_stm.pdf, some of the design tradeoffs mention book keeping and consistency problems. Hence, I believe that drawbacks to TM is mostly the overhead of everything.
VP7
@Berry. Nothing comes for free :D.
The implementations of TMs come with huge overhead of book-keeping and versioning.
It is very course grain in nature (in general).
As Kayvon said, TM is a good candidate for a situation where you are willing to compromise on 10% reduction in performance (compared to a lock free implementation or fine grain locks), but makes the programmer's life easy by a huge factor.
I didn't see too many drawbacks to TM. Are there any serious ones?
I believe that transactional memory requires you to do MUCH more during the compilation process if you're using a software based version. This requires a lot of overhead in your computation. Also, as far as I know, there isn't a very good version of transactional memory which makes the least amount of atomic operations. If you look at http://web.cse.ohio-state.edu/~agrawal/788-su08/Papers/week4/design_tradeoffs_modern_stm.pdf, some of the design tradeoffs mention book keeping and consistency problems. Hence, I believe that drawbacks to TM is mostly the overhead of everything.
@Berry. Nothing comes for free :D.
As Kayvon said, TM is a good candidate for a situation where you are willing to compromise on 10% reduction in performance (compared to a lock free implementation or fine grain locks), but makes the programmer's life easy by a huge factor.