Actually, Software Transactional Memory is the correct term. To wit:
"Software Transactional Memory", Nir Shavit and Dan Toutiou, 1997.
The confusion is part of what I'm raging about ;) You can't simply say, "well, by 'software' I mean whatever I want it to mean, and not what I'm implying".
Fact is, real STM does not exist. It doesn't exist in the JVM, it doesn't exist anywhere in production (notwithstanding the Rock CPU mention). It can only exist w/ a universal primitive like LL/SC, as proven by, I believe, Herlihy.
Everything else can deadlock, and can livelock (if you're providing STM semantics).
Now, as pointed out elsethread, yes, STM can provide conceptual amelioration regarding the semantics of a language. But when that new language is running on your desktop, there is no way to "fake" it.
Existing STM is analagous to Perl5/6's "quantum" operators. Conceptually useful, but it's not literally doing it.
But don't take my word for it. Here's a small list of relevant material. These are the papers I still have in my research directory:
"Software Transactional Memory", Shavit and Toutiou, 1997.
"A Methodology for Implementing Highly Concurrent Data Objects", Herlihy, 1993.
"A Methodology for Implementing Highly Concurrent Data Structures", Herlihy, 1990.
"A Practical Multi-Word Compare-and-Swap Operation", Harris, Fraser, Pratt, 2002.
"Impossibility and Universality Results for Wait-Free Synchronization", Herlihy, 1988.
"Practical Lock-Free and Wait-Free LL:SC:VL Implementations Using 64-bit CAS", Michael, 2004.