Of course it is still early in the process, and while I’ve got some ideas for my implementation, and have started prototyping parts of it, most of the time has been spent catching up on all the existing work in the field.

Little did I know when I accepted the subject that there’d been written that many papers about it over the last decade. Phew… A commenter asked me for the references I found useful, so here’s an incomplete list:

Tranactional Memory Bibliography: This site contains an up-to-date and extremely comprehensive list of references to everything written aobut STM. Just the sheer number of links out from that site is depressing, but it’s obviously a wonderful place to get an overview of what’s available.

Transactional Memory: I bought this book after noticing that almost every paper on STM referenced it. And it was money well spent. The book is well written, explains the subject clearly, and covers pretty much everything I wanted to know. It is split into three main chapters (not counting the introduction):

The first chapter discusses TM purely from a user’s perspective. What should the API look like, what do we, as programmers want or need from a TM implementation, what should the semantics be, and what extensions might be useful? It explains a number of important concepts, such as weak/strong isolation, serializability and linearizability, direct and deferred update and many others. But mostly, this chapter is fantastic as a discussion of what TM research should aim towards. Without getting bogged down in implementation details, it focuses simply on how we’d like it to work (and on the many open questions where we still don’t know which semantics would make sense or be most useful).

The second chapter is useful as a shortcut, allowing newcomers such as me to catch up on the last decade’s research. It summarizes all the important papers on STM, from the earliest precursors dating back to the 70’s, up to 2006 when the book was published. The various implementations and results are briefly described, in enough detail for me to understand the main ideas presented, and determine whether to look up the paper in question and read it in full.

The third chapter gives a similar treatment to Hardware Transactional Memory, and since that is outside the scope of my project, I’ve skipped lightly over this for now, although I may just read it out of curiosity later on. In short, it’s a great book for anyone trying to find their way in the jungle of TM papers.

Haskell STM: Simon Peyton Jones and others at Microsoft Research have done some truly impressive work on a STM implementation for Concurrent Haskell. While those of us working in a messy language like C++ can’t aspire for such a clean and elegant implementation, there are still many good ideas we can borrow.

And finally, a few individual papers I’ve gotten a lot out of:

Software Transactional Memory Should Not be Obstruction-Free: As STM grew out of research into lock-free datastructures and distributed systems, the early work was downright obsessed about making transactions nonblocking. It took this paper to take a step back and ask whether this requirement actually makes sense for the rest of us. And guess what? It doesn’t. It complicates the STM implementations, and prevents some very useful optimizations.

What Really Makes Transactions Faster followed up on the above, discussing a number of other ways in which the performance of STM systems could be improved.

And finally, the earlier thesis that drew me into the subject:

A Software Transactional Memory Library for C++: This is the first implementation I’ve seen which seriously targets C++. Of course many prior C++ implementations exist, but they’ve generally relied on either C or Java idioms, resulting in an uglier, more error-prone interface, and the inability to perform a number of optimizations. This paper describes a proper modern C++ implementation, relying on generic programming, template metaprogramming and all the other tricks in a C++ programmer’s toolbox.

But now it is official. I handed in all the paperwork (in six copies, what do they need all that paper for?), got the signature from my advisor and everything else yesterday. I have now officially started on my thesis. The subject?

Implementing a Software Transactional Memory (STM) library in C++0x. (Or rather, in C++, using whatever C++0x features current compilers have support for. In particular, I can see good uses of rvalue references and lambda expressions, which, luckily, the Visual C++ 2010 beta has support for.

And I am super psyched up about it. The subject seems a lot of fun. Of course I’ve got a lot of reading to do, catching up on all the existing research in the area (Two weeks ago, I had barely heard of STM before, so I can’t claim to be an expert on the field yet ;))

However, the C++0x aspect seems to be almost untouched in previous work¹, which is obviously nice. Feels good to be able to contribute something new.

My deadline is March 1st, 2010, almost exactly 6 months from now. I’m going to push myself to get a prototype up as early as possible. So the first few weeks are going to be busy. Once I get started properly, I’ll be able to vary the pace a bit more, taking more time out for the blog, work and everything else.

But I’m still not sure what I want to write about. I’ve got a few ideas, mainly by asking some of the professors I might want as advisors if they had any interesting projects lying around.

So far, this is what I have:

1. Efficient inversion of huge block-diagonal matrices on a CELL processor
2. Multi-threaded implementation of the C++ STL
3. writing a GPU shader language, probably in a more functional style than existing languages, taking advantage of the inherently side-effects-free platform

The first one is based on a project I did last year. It was fun, and there’s still plenty left to do. The algorithm may sound dull (matrix inversion?), but the fun part is implementing it on a CELL, and the algorithm has a lot of steps that are challenging to implement efficiently on the hardware. Working with a CELL is interesting, and since I’ve done it before, I can get started relatively quickly, sidestepping all the beginners’ trouble figuring out how to program the monster. So that’s definitely an option. On the downside, it’s, well, stuff I’ve done before, more or less.

The second sounds like a blast, to be honest. It could be a lot of fun. Unlike the CELL project, I wouldn’t have to worry about weird hardware limitations, but can instead focus on crazy C++ templates and generic programming. I still have to figure out a specific angle on it though. Simply implementing multithreaded versions of the functions in the algorithm header is obvious, but has been done already. Implementing the containers with multithreading in mind might be interesting, but then the problem is no longer that of automatically parallelizing code (which is fun), but rather that of ensuring our code is thread-safe (which is… less fun). A third option might be to use such a parallel STL implementation to solve some problem.

The third one is a pet project I got the idea for a year or so ago. I’m still not sure about it. I think the basic idea is good, and it could be fun, (and would be relevant if I want to get into the games industry after I graduate) but there are a lot of unknowns involved:

• I’m not exactly a hardcore compiler writer. I’ve taken both the basic and advanced compiler courses at uni, and passed them with good grades and without too much trouble, but all the more theoretical courses about partial evaluation, big-step semantics and other fancy theory just leave me cold. I doubt any of that will be necessary, but.… is it a risk I want to take on my thesis?
• GPUs have a lot of unusual hardware characteristics I’ll have to deal with — first of course, that they are inherently SIMD instruction sets, second that there is very little support for branch/jump instructions, a fixed number of registers and no memory you can spill into. Writing a compiler for that seems
• It’ll most likely have to target one of the existing shader languages (Cg, GLSL, HLSL). Is that practical? How should it interface with OpenGL/Direct3D, if it were to be useful in practice?
• It seems like a lot of work…

So yeah, the last one has a certain attraction in that it’s my idea, where the others are suggestions I’ve been given, but it’s also scary as hell. And like I said, the two first suggestions are great fun too.

What to do? I’ll have to decide in a couple of days. I don’t want to wait any longer before starting on it.