Been a bit quiet on the blog front lately. I’ve been busy getting my master’s thesis off the ground.
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 work1, 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.
-
Unsurprisingly, as 1) most current research has been done by people who knew a lot about STM, and not so much about modern C++, 2) C++0x has seemed a long way off, and 3) compiler support for 0x features was almost nonexistent. ↩
Exciting! I look forward to seeing the end result.
Do you plan on focusing how C++0x influences the implementation of an STM library, or on how features like lambdas make using the library easier, or …?
I imagine a fair chunk of the work that went in to more precisely defining the C++0x memory model, along with e.g. standardized atomics, will be of great help for anybody interested in creating something like a STM library, even if those improvements don’t directly alter the programmer’s experience of using the STM library.
I was thinking of both implementation and usage, actually. Rvalue refs make the implementation more robust and more efficient (since move operations can typically produce better exception guarantees than copying, and they’re faster as well, so that helps implementation). Lambdas are an obvious way to make the usage easier. If the library depends on the user supplying functors to define transactions, lambdas make it a lot easier for the user to define these.
I’m still not sure about the practical value of the memory model specifications for a few reasons. First, much of it is really just standardizing what every compiler already does, so it’s great on paper, but makes little difference in practice. Second, to make use of stuff like the standardized atomics I have to find a compiler which implements those as well as the other features I plan to use. But yeah, in the long run, those are obviously going to be a huge help in doing stuff like this while staying within the bounds of the standard.
Oh, and I’d also very much like to know which STM papers you find interesting/worthwhile, even the ones that don’t end up in your References. If you don’t mind, of course! ;-)