Features Download
From: Aldy Hernandez <aldyh <at> redhat.com>
Subject: Potentially merging the transactional-memory branch into mainline.
Newsgroups: gmane.comp.gcc.devel
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:


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

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.


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.
CD: 4ms