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
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