Subject: Potentially merging the transactional-memory branch into mainline.
Date: Monday 31st October 2011 22:33:28 UTC (over 6 years ago)
This is somewhat of a me-too message for the transactional-memory work. We would also like it to be considered for merging with mainline before the end of stage1. We have a kept a wiki here: http://gcc.gnu.org/wiki/TransactionalMemory What it is ========== From the wiki... Transactional memory is intended to make programming with threads simpler. As with databases, a transaction is a unit of work that either completes in its entirety or has no effect at all. Further, transactions are isolated from each other such that each transaction sees a consistent view of memory. Transactional memory comes in two forms: a Software Transactional Memory (STM) system uses locks or other standard atomic instructions to do its job. A Hardware Transactional Memory (HTM) system uses features of the cpu to implement the requirements of the transaction directly (e.g. Rock processor). Most HTM systems are best effort, which means that the transaction can fail for unrelated reasons. Thus almost all systems that incorporate HTM also have a STM component and are thus termed Hybrid Transactional Memory systems. The transactional memory system to be implemented in GCC provides single lock atomicity semantics. That is, a program behaves as if a single global lock guards each transaction. What it involves ================ We have implemented the latest spec from the multi-vendor transactional memory group that includes AMD, Intel, Oracle, and others. The last official spec is what is in the wiki above, yet there are some minor changes to the keywords that are currently being finalized in the final document (but have already been agreed upon), and will be published shortly. It is my understanding (Torvald, correct me if I'm wrong), that the current implementation is what has been agreed to by the committee, and has been given a favorable nod by various members of the C++ standardization committee. Most importantly, the keywords are agreed upon. There are changes to the C and C++ front-end, and a software library (libitm) to go along with it. The library works on x86-64, x86-32, and Richard's favorite, Alpha :-). Porting to other architectures should be a straightforward affair. Status ====== The current implementation runs the common TM benchmarks correctly, albeit there is still work to be done to improve performance. There are a handful of failed compiler tests on the included transactional memory testsuite (g*.dg/tm/*), but they are all missed optimizations, which we hope to have fixed after the merge. What's left =========== Torvald is working on some recent changes to noexcept, and we should have this working in a few days. I will be removing the cancel-throw construct which didn't make it in the final spec. I should have that done tomorrow. The final word ============== Seeing that a global maintainer has been lead on this for a while, I suspect there isn't much to review formally. I believe the only bits that Richard isn't directly responsible for are the C++ front-end changes. So what is the opinion/consensus on merging the branch? It would be nice to get this infrastructure in place as well so we can get people to start using it, and then we can work out any issues that arise. I have no idea how this happened, but apparently I'm on the hook for merging both the cxx-mem-model and this branch (if/when one/both get approved). If this gets approved, I'd prefer to get the cxx-mem-model branch merged first, and the transactional-memory branch later during the week. I will be partially available during the weekend, and definitely during next week.