GCC 4.7 adds transactional memory extensions for C/C++

On a related note, the cilkplus branch of Gcc 4.7 contains the cilk work-stealing multithreading runtime and language extension that intel has open sourced. <a href="http://software.intel.com/en-us/articles/intel-cilk-plus-specification/" rel="nofollow">http://software.intel.com/en-us/articles/intel-cilk-plus-spe...</a><p>Exciting times ahead.

I think this is the implementation (pdf article available): <a href="http://www.velox-project.eu/velox-transactional-memory-stack" rel="nofollow">http://www.velox-project.eu/velox-transactional-memory-stack</a><p>They point to the Velox project, which has many published papers. But this paper has Ulrich Drepper of Red Hat as a co-author. Since Drepper is active in glibc, I can imagine he worked with them on integration. The notation in the article also looks like what's shown on the website.<p>There's plenty of other work that could have gone into this implementation: <a href="http://www.velox-project.eu/publications" rel="nofollow">http://www.velox-project.eu/publications</a> There's a full TM system that tries to use idle cores or SMT threads (also known as hyperthreads) for the transactions, called STM2. Then some papers on lock-free techniques, static analysis, and a benchmark suite. There's also what looks like a direct response infamous "STM: Why Is It Only a Research Toy?" (<a href="http://queue.acm.org/detail.cfm?id=1454466" rel="nofollow">http://queue.acm.org/detail.cfm?id=1454466</a>) article: <a href="http://www.velox-project.eu/why-stm-can-be-more-research-toy" rel="nofollow">http://www.velox-project.eu/why-stm-can-be-more-research-toy</a><p>I don't know for sure, of course. The STM2 paper published at PACT of this year also looks interesting. Email me if you'd like to read it.<p>Edit: the paper I linked to at the top says it's implemented in gcc.

Is this the first step towards a GCC that would have all the features of Clojure? That would be incredibly useful to me for one - I love Clojure but just cannot make any sense of what the JVM tells me when I screw up.

<a href="http://nickclifton.livejournal.com/9501.html" rel="nofollow">http://nickclifton.livejournal.com/9501.html</a><p>"The support implements and tracks the Linux variant of Intel's Transactional Memory ABI specification document. Currently this is at revision 1.1, (May 6 2009). For more information see:<p><a href="http://software.intel.com/en-us/articles/intel-c-stm-compiler-prototype-edition/" rel="nofollow">http://software.intel.com/en-us/articles/intel-c-stm-compile...</a> "

i have a <i>fundamental</i> question regarding stm in general: for 'manual' locking, we need to worry about dead-locks, for stm, i <i>feel</i> live-lock would be more sinister, and extremely hard to debug/reason about. not to mention the fact that, it would make client code non-composable as the transaction size or the system load increases.<p>or am i missing something ? thanks for your insights !

I was hoping for more information on how they implement it.. there's nothing in there about which hardware facilities they use, and they say that at worst STM is a global lock for the process.<p>Hopefully they're at least using some kind of compiler analysis to only use the same lock across transactions if it's touching the same memory addresses (pessimistically of course)?

This is pretty cool. Is it done naively and using one global lock, or is it be more intelligent? Can GCC identify what memory location require locking for a given transaction, and lock just those? What is the granularity?