Are we asking too much of transactional memory?

Posted by Carl Seleborg on Stack Overflow See other posts from Stack Overflow or by Carl Seleborg
Published on 2009-05-21T21:33:14Z Indexed on 2010/05/18 14:00 UTC
Read the original article Hit count: 361

Filed under:
|
|

I've been reading up a lot about transactional memory lately. There is a bit of hype around TM, so a lot of people are enthusiastic about it, and it does provide solutions for painful problems with locking, but you regularly also see complaints:

  • You can't do I/O
  • You have to write your atomic sections so they can run several times (be careful with your local variables!)
  • Software transactional memory offers poor performance
  • [Insert your pet peeve here]

I understand these concerns: more often than not, you find articles about STMs that only run on some particular hardware that supports some really nifty atomic operation (like LL/SC), or it has to be supported by some imaginary compiler, or it requires that all accesses to memory be transactional, it introduces type constraints monad-style, etc. And above all: these are real problems.

This has lead me to ask myself: what speaks against local use of transactional memory as a replacement for locks? Would this already bring enough value, or must transactional memory be used all over the place if used at all?

© Stack Overflow or respective owner

Related posts about transactional-memory

Related posts about locking