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.
