IBM's Alphaworks Software Transactional Memory Compiler

Michael_Wong — Tue, 11 Aug 2009 17:02:44 GMT

Transactional Memory (TM) is a high level abstraction for supporting a safe mutable shared state, such that the user does not have to worry about the low-level details of locking and sharing of global resources. It is basically a class of optimistic speculation techniques such that groups of memory operations are bundled as an atomic operation such that it can resolves the problems with locks, possibly support composability.

The basic idea is to move your group of atomic operations through, assuming that it will be successful, and only rollback when a conflict actually occurs.

At the moment, much of the ideas of TM are there as a way to test out the idea, and possibly be integrated into some future hybrid system. Even practitioners of TM knows there is a certain amount of hype that we have to deal with in any new technology before it drops to a trough and rebounds back to a realistic plateau.

A number of vendors have planned both hardware and software implementations of Transactional Memory.

The software transactional memory compilers from different vendors all use different syntax, and this creates a basic problem with interoperability, and common porting of code. I will deal with this in the next post.

IBM is also working in this area, and has released an Alphaworks compiler supporting Software Transaction, actually last year.

The IBM XL C/C++ for Transactional Memory for AIX is also accessible from the Resource Library of the C/C++ Cafe.

The public domain STM runtime is compatible with the AlphaWorks XLC STM release.
It was released through the Amino Concurrency Building Blocks project
The source code is here

I will have more to say about the Amino Building Blocks in a future post.

The View (trip report) from BoostCon09

Michael_Wong — Thu, 28 May 2009 00:47:16 GMT

I apologize for lack of updates recently as an addition to the family has kept me hopping.

I have still been keeping up my parallel programming work by a recent talk on C++0x Multithreading at BoostCon 09:

http://www.boostcon.com/program#schedule

My two talks (the other one was an overview of C++0x and compiler support which can be seen here:
http://www-949.ibm.com/software/rational/cafe/blogs/cpp-standard/2009/05/26/the-view-or-trip-report-from-the-mar-2009-c-standard-meeting) seem packed with about 60 people in an auditorium for about 90 minutes. Here is a trip report from a fellow speaker Justin Gottschlich who attended my talks:

http://par-con.blogspot.com/

The slides and video should be online soon.
A second trip report review is by Emil Dotchevski:

http://revergestudios.com/reblog/index.php?n=ReCode.BoostCon09

Justin gave an excellent talk on a proposed Boost Transactional Memory Library which he is collaborating with the Father of TM: Maurice Herlihy.

I have been involved in Transactional Memory for a few years now and knows its hype, promise and pitfalls. Still I felt I was stirred by Justin's excellent oratory skills, pitching this technology. The idea of doing TM as a pure library is not easy, although it does get the technology into the hands of everyone as fast as possible. Language changes take time to get right. I should know and will discuss in a future post.

Please read their excellent trip reports for the details. I will turn my discussion on something else that is also interesting to me personally, but may not have much to do with Parallel programming.

BoostCon 09, as with previous BoostCon was an exciting experience. Without intentionally touting my own horn, BoostCon09 is rich with speakers of experience in the field. They choose their speaker carefully from the pantheon of C++. Last year was Bjarne Stroustrup. This year was Andrei Alexandrescu, whose topic is Iterators Must Go.

Andrei gave many reasons why iterators, once a good idea, are unsuitable as we move forward. For me, the most interesting argument is that iterators are not well suited to multithreaded programming, because many of the idea of stack pop and push can only work in single thread unless we change the interface.

BoostCon, in my opinion is rapidly becoming the leading C++ conference, in direct competition with SD West, and ACCU. All are packed with workshops, and knowledgeable speakers.

This year, there was a distinct track of parallel programming theme, which included:

Joel Falcou: High-Level Parallel Programming EDSL - A BOOST libraries use case
Stephan T. Lavavej: Parallel Patterns Library in Visual Studio 2010
Justin Gottschlich, Jeremy Siek: Boost + Software Transactional Memory
Troy Straszheim: Kamasu: Parallel computing on the GPU with boost::proto

and of course, yours truly's:

Michael Wong: Multithreaded C++0x: The Dawn of a New Standard

All this makes me want to suggest a special track for parallel programming for Boost in future years.

I attended some of the 0x tutorials and found that I still had things that I didn't know. This is not surprising given the depth of C++0x.

The other interesting part was the Cmake tutorial. Boost build has used bjam since the beginning. This build tool, while interesting in its own right has many peculiarities which makes its adoption not a trivial task for building Boost on IBM systems. From the stories we heard around Boostcon, the same seems to apply to other environments.

Recently, there has been a move towards using cmake as a truly better build tool. From what I can see from the workshop, they are right and I am eager to move our Boost build to a cmake system, especially if Boost is moving in that direction, to rid us of the problems that bjam has caused.

http://www.cmake.org/

How does cmake differ form the traditional unix make?
Unlike make, it does not actually do the software build, but instead generates standard build scripts (makefiles on Unix, project file for Windows, workspaces for Eclipse/CDT), that makes it easier to adopt to various systems.

Cmake was started as part of the Insight visual ToolKit build from Kitware, and has since migrated into many products. The real explosion occurred with adoption of cmake by KDE. Since then, even more software is converting to cmake.

Cmake is so far able to build Boost, but is not able yet to run its builtin tests. This is a problem that I am sure will be rectified.

The beauty is that cmake is available already as a binary on AIX systems.

I worked with Troy Straszheim and Brad King to try getting cmake working on our Boost build. I got half way but found a problem which I hope to resolve.

We support Boost because IBM AIX and Linux xlC++ compilers have been tested with Boost with support in V8 with 1.32, then V9 with 1.34, and V10.1 with 1.34.1.

You can see our Boost test results here:
http://www.ibm.com/support/docview.wss?rs=2239&context=SSJT9L&uid=swg27006911

Parallel and Multi-Core Computing with C/C++

IBM's Alphaworks Software Transactional Memory Compiler

The View (trip report) from BoostCon09