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)?
Within a transaction block, the results of all reads are stored (to a local, hidden variable). When the transaction is about to finish, all reads are repeated and if any of them yields a different result, the transaction is restarted. When the transaction is committed, there will likely be some kind of a global lock (that will be held for a very small time).
As GCC probably doesn't require any kind of threading or locking, it's most likely that the write lock will be a spinlock using an atomic read-modify-write and some kind of yield instruction (monitor/mwait on new cpu's, pause on older).
As far as I can see, there really aren't lots of other methods to implement STM, especially from within the C compiler.
Exciting times ahead.
But you'll have to be more specific with your complaints. What kind of parallel programs are you trying to design? What similar infrastructures have you worked with?
How would you implement work-stealing in pure C?
But the Deep Thinkers in the Clojure community feel your stack trace pain, and now that 1.3 is in the can it seems to me that there was renewed enthusiasm at Conj for doing something about debugging clarity. You shouldn't give up hope yet.
or am i missing something ? thanks for your insights !
1. If live locks are a problem coming from load, rather than bad interactions between components, you are likely to have a choice between (i) pessimistic, where most threads do nothing vs. (ii) optimistic, where most threads do work that gets thrown away. In practice, optimistic tends to be faster, because it is not better to do nothing than do worthless work and the committer is working with the results of successful computations, where the locking algorithm doesn't know which computations might not work out;
2. Extremely hard to reason about is just how it is with threads. I haven't done enough concurrent programming to really say, but the optimistic commit model seems to be more intuitive than the pessimistic lock mode. Peyton Jones makes this point forcefully in Beautiful Concurrency http://research.microsoft.com/pubs/74063/beautiful.pdf
[1]: http://www.velox-project.eu/velox-transactional-memory-stack (courtesy scott_s)
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.
There's plenty of other work that could have gone into this implementation: http://www.velox-project.eu/publications 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?" (http://queue.acm.org/detail.cfm?id=1454466) article: http://www.velox-project.eu/why-stm-can-be-more-research-toy
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.
Edit: the paper I linked to at the top says it's implemented in gcc.
"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:
http://software.intel.com/en-us/articles/intel-c-stm-compile... "
