Of course, a few people assumed I was talking in absolutes, that because the practice of dogfooding is not perfect, it must be evil. That’s a bit of an exaggeration.

I never said that “dogfooding is bad”. But dogfooding generally means using your product on a daily basis. Not just poking around with it, or checking it out, but actually using it as your primary tool for… whatever the product is supposed to do for you.

This implies that you can’t really use a lot of other products as intensively while you’re dogfooding your own. A developer on the Visual Studio team can’t both use VS10 for all development, and at the same time use Eclipse, Vim and Emacs on a daily basis. If he were to use all those, there would no longer be enough time left to use VS10, and so he wouldn’t be dogfooding it.

And that is the problem. Dogfooding is a valuable way to incrementally improve and polish your product. But it also takes up time that could have been spent using someone else’s product. And when you use a product in your daily life, you become blind to a number of its weaknesses.

One of the Reddit commenters mentioned a lovely example: Java developers, people who write Java and nothing else, don’t really see the need for closures. They just don’t really consider it a valuable feature. But pretty much everyone else does. Does this mean that in Java, alone of all languages, closures are not relevant? C# programmers got closures and are ecstatic about them. C++ programmers are about to get closures, and everyone’s just itching for it to happen. Functional languages always had closures, and programmers in those languages just can’t live without them. Are we to believe that specifically in Java, closures just do not matter?

Or does it just mean that the Java developer doesn’t yet realize how much easier closures could make his job? He doesn’t realize this because he’s never had the chance to use them. He’s stuck in the world of Java as it looks today, and if you were to ask him what he’d like changed about the language, he’s not going to say “closures” or “higher order functions”, or even “templates” or “type inference”. He’s going to come up with some small incremental improvement. Wouldn’t it be nice if class X was added to the class library? Wouldn’t it be nice if Y was named differently? Wouldn’t some shorthand syntax for things you can do already be nice?

And the same is true for dogfooding. Visual Studio is slow. Many common operations cause multiple seconds of wait time. Adding an empty file to a project in VS2008 is painful sometimes. But oddly enough, I only really notice it when I’ve gotten used to Vim or Emacs or some other alternative IDE or code editor, which isn’t so slow. Its project structure is fundamentally broken, but I only really notice this when I’ve just spent a few weeks playing around with makefiles¹. And the same goes for the Windows Mobile phone I had a few years ago. While it worked, I tolerated its quirks. Apart from a few instances when it went really haywire, it wasn’t so bad. Sure, it was sluggish and needed to be rebooted regularly, and sure, the interface wasn’t exactly pretty or convenient to use. But it worked, most of the time, and I got used to it. I didn’t love it, and I didn’t think it was a particularly good phone, or platform or OS, but it was usable. Then the phone broke, and it took me a few weeks with my replacement phone to realize just how much better everything else was. My Windows Mobile phone sucked. I just didn’t realize it until I got to use a different one on a daily basis.

But let me reiterate, dogfooding is a good thing. There’s no doubt of that. Your product can only get better by having your developers actually use it in the same ways that end users are expected to. But if dogfooding is all you do, then the world will pass you by.

So why did I dig this old post up again?

Because Visual Studio 2010 is about to be released, and as we may have expected, this means Microsoft’s developers have to beat their drum a bit about how awesome it is because it’s been dogfooded.

Soma just seems to forget that the glaring performance issues in both beta 1 and 2 came as a huge surprise to Microsoft until the betas had been released in the wild. As much as they dogfooded it, it didn’t give them the information they needed: that VS10 is painfully slow compared to everything else, including VS9.

Both betas were released pretty much with the message “Don’t worry. It might use a lot of managed code and use a completely new WPF-based editor. But it runs really well and is just as fast as previous versions of Visual Studio”.

There were two reasons for this. One seems to be (according to another Microsoft developer’s blog post which I can’t seem to find at the moment, unfortunately) that they simply didn’t collect the right metrics from all their dogfooders. A lot of their developers did think it was painfully slow, but were never asked how they felt about the current performance level.

And the other is obviously that all their dogfooders were using VS10 in their day-to-day work. They had nothing else to compare it with. They weren’t using Eclipse or Vim or Emacs or even VS9 or VS6 in their daily work. So they became used to the downright painful performance.

But once they released the beta into the wild, it was obvious to everyone else, all those people who had not been using VS10 on a daily basis for months, that it was a huge step backwards.

So yes Microsoft, you’ve heavily dogfooded VS10. No doubt about that. But let’s not pretend that it solved all your problems, or that it gave you the best possible product. In reality, it led to you scrambling the last 6 months to bring the performance back up to where it should have been all along, and where you’d probably have kept it if you’d used other IDE’s occasionally so that you’d had a basis for comparing performance.

It’s not that dogfooding is bad. It’s just not enough. And it is not, in itself, a selling point or a proof of quality.

On monday the 12th of April, I’m going to defend my master’s thesis. If you’re in the area, and are geeky enough to find it interesting, feel free to drop by.

The precise place and time is: 15:00, April 12, 2010

Room S125 / 3–1-25 DIKU (Datalogisk Institut) Universitetsparken 1 København Ø

Looks like I’m going to be busy the next couple of days preparing my presentation.

That is all.

Here is what I’ve previously written about my thesis on the blog, here is what Wikipedia has to say on the subject, and here is the thesis itself, including source code.

I’ve been meaning to write this post pretty much for the last month. The reason I’m finally doing it is that I also wanted to drop a quick line on a cute aprils fool joke that should be of interest to a lot of gamers:

Rock, Paper, Shotgun dedicated the entire day to perfectly ordinary PC game reporting/blogging as if it’d been April 1st, 1993. Cute and intelligent, and served as a fun trip down memory lane. Nice idea, and a nice change from the usual fare of everyone trying to pull off outrageous or absurd stories ad nauseam. Especially as there seemed to be practically no worthwhile pranks to be found anywhere this year (even Google had some pretty tame ones), your up to the minute coverage of PC gaming news as of 17 years ago really made the day.

Many people are in love with the Singleton pattern. Others — a small minority, I suspect — consider it a mistake, an anti-pattern, or something that was only ever included in the Design Patterns book as a lifeline to procedural programmers who couldn’t really figure out this OOP thing.

I won’t pretend to be half as clever as all the people who have already written about the problems with singletons years ago, and I don’t think I have anything new to bring to the table. But it is a pattern I learned to loathe very soon after I first saw it in use. (Singletons do sound attractive when you first hear of them. But they pale a bit when you end up having to tear up and rewrite half your code just because all your singleton classes start revealing their shortcomings) And for a long time now, I’ve tried to convince other programmers that Singletons have some serious problems. Recently, it seems like I’ve even gotten noticed for it on StackOverflow.

First, GMan posts an answer to one question, and I comment with a mild disagreement, and the discussion goes on for a few more comments. As singleton rants go, this one is pretty mild, and I don’t really think about it any further. Then, a few weeks later, I discover his blog and this post. Wow! A convert. A person I know to be extremely bright and a knowledgeable programmer has changed his mind in response to something I said… I’m flattered.

And today, I noticed another question being posted, which had both Boost and Singletons in the title — how could I resist? Two subjects I enjoy talking about, even if the things I say about them are very different. Surprisingly, the comments there already mentioned me, and some of my earlier answers regarding singletons. Should I be flattered that people have started bringing my name up when discussing Singletons?

Anyway, one of the comments also suggested I write a blog post describing my argument in detail. So I will.

Two wrongs don’t make a right

There are a lot of problems with singletons. In fact, it’s surprising that so many people still consider the pattern useful, when it is afflicted with so many weaknesses and flaws. However, for now I will single out the two that I feel are the most fundamental: not just problems with how a singleton works, but with what they’re trying to achieve:

A singleton, as defined by the Gang of Four, combines two properties:

• it guarantees that exactly one instance of an object exists. While that one instance is typically created lazily, so it doesn’t technically exist throughout the entire application’s lifetime, it always seems to the programmer as if precisely one instance exists, and
• it guarantees global access to this one instance.

Let’s pick those apart a bit. The last one is easiest: it is, by now, fairly common knowledge that global state is bad. We don’t like global variables, we don’t like static class members, we don’t like anything that makes it harder to isolate bits of our code. Dependence on global state causes a lot of problems: it hurts parallelism, as access to global mutable state generally has to be serialized through the use of locks. It makes dependencies harder to detect and control (any function might silently decide to access our singleton. The function signature says nothing about this, so we have to read the source code of the function to determine if this is the case. And because it is so convenient to always just add a reference to a singleton, we tend to do it a lot. When you have a singleton, you quickly end up in a situation where three out of four classes depend on it. How did that happen? Why, logically speaking, do so many classes need direct access to the database? Or the renderer? Is that good design? Not only is this messy, it’s also painfully hard to fix after the fact. Once we have these dependencies on global objects everywhere, that’s a lot of code we need to change to eliminate the global. Almost every class will be impacted by the change, and a huge number of functions have to have their signatures modified to take that extra parameter replacing the global. Or even worse, the function has to be completely rewritten to eliminate the need for whatever service the singleton provided. The more globals you have in your project, the more your dependency graph starts resembling spaghetti. And the harder it gets to clean it up.

It hurts reusability, as code taken from one project and inserted into another may break because it depended on globals not present in the new project. It hurts testability partly for the same reason, a unit test testing a class must suddenly provide a number of globals as well just for the code under test to compile, but also because global state makes tests less deterministic. One test might change the state of this global, affecting the outcome of the next test to run.

Globals are bad for a lot of reasons. They have their uses, no doubt about that, but we should be suspicious whenever the solution to a problem involves global data. It might be the best solution, but often, it is more trouble than it’s worth.

The other point is more subtle. Why do I object to a class enforcing that “only one instance may exist”? It’s really just common sense. As the Agile movement tells us, we don’t really know what our code is going to look like tomorrow. Over the course of development, we have to adapt to changes, modify our code, revise decisions already made. Why put roadblocks in front of us? Why make it harder to adapt to unforeseen changes or requirements?

Today, I might think that I need only one logger instance. But what if I realize tomorrow that I need two? That’s not so far fetched. We may have one log we write ad-hoc messages intended for debugging purposes, solely to be read by developers, and another formalized log, where structured messages are written when predetermined events occur, so that the application can be monitored in production. Sure, we could define the two as completely separate classes, and then we’d only need one instance of each (but then we’d start duplicating code). Or we could use the same log instance to write to both logs (but then the logging code would become more complex, having to interleave two separate and non-overlapping logs.

Once we’ve accepted that an application may need more than one logger, shouldn’t we do ourselves the favor of ensuring that our loggers can be instantiated more than once, just in case it turns out to be the right thing to do? We’re not even adding any complexity, there’s no cost associated with this. On the contrary, we’re removing significant complexity. Thread-safe singletons are surprisingly hard to get right. Dependencies between singletons are tricky and circular ones can cause them to blow up in all sorts of fun ways. And let’s not even get into how to handle anything our singletons might do while the application is shutting down. What if the database singleton tries to write a simple “goodbye” log message to the log singleton? What if the log singleton got destroyed before the database one? Ouch.

Singletons are hard to write and hard to use. Removing them only simplifies our code, so if it also enables us to better adapt to unforeseen requirements, why shouldn’t we remove them?

Not convinced? Let’s think of some other examples then:

• the application configuration should be a singleton, right? We obviously can’t have more than one of those! Wrong. We can. We often do. Think about what happens when the user opens the “Options” screen and modifies the settings. During that time, two sets of settings exist: the “applied” settings that are currently in effect, and the “speculative” ones, currently being picked out by the user. Once he clicks OK, the speculative changes should be applied, replacing the ones that were previously in effect. But until then, we have two sets of settings to maintain.
• a database connection pool then! If we have more than one pool of connections, we can’t efficiently share them! Correct, but perhaps we don’t want to share them. Perhaps I want to ensure that library A has one pool of 10 connections available to it, component B has a smaller pool of 3 connections, an components C, D and E use the global pool with however many connections it supplies. That would ensure that no matter the number of threads running in component B, it’ll never starve out other components trying to access the database. It can never hold more than three connections, leaving room for other components. Of course, in the common case, we do want all connections to be shared in one single pool. But perhaps not always. So yes, there should probably be a globally accessible default pool available. But why shouldn’t it also be possible to define new local pools if the user deems it necessary? Why limit ourselves to one instance?

And even if you do come up with some case where we absolutely must never have more than one instance, where it would make the sky come crashing down on us, consider testing. Consider that each of your unit tests should set up the environment it needs, and run within that environment, in isolation from other tests. That means that every test should create its own logger instance, or database pool instance, or whatever else our singletons are doing, just so it can avoid being polluted by stateful changes made by earlier tests. Each unit test for the Direct3D renderer should set up its own renderer object. Each physics simulation test should initialize the physics engine first, and shut it down again after use. Singletons don’t easily allow that. Sure, we can extend them with explicit Create() and Destroy() methods, but then our abstraction is starting to get leaky. We can no longer assume that precisely one instance exists, because we might have just destroyed the one that existed.

The “exactly one instance” guarantee removes flexibility from our code that we may need, in order to enforce a constraint that we definitely don’t need. Where’s the harm in allowing the user to create more than one instance if he decides to?

C++ programmers are familiar with std::cout, the standard output stream. Funny thing about this, it is a simple global object. We can obviously never have more than one standard output stream. But we can have more than one stream. The standard library just initializes one of them to point to the standard output, and saves it as a global variable. We don’t need it to be a singleton, we don’t even need it to be a static class specially defined for the purpose. We just need a stream, defined somewhere where it’s globally accessible.

True, a sufficiently stupid programmer could create a new stream when he intended to write to std::cout, and true, a singleton implementation would have prevented that. But is it worth it? When was the last time you saw someone accidentally invoke std::ostream() << "Hello world";, when they intended to write std::cout << "Hello world";? It’s not the most common typo I’ve seen.

We don’t need to prevent multiple instantiations. If we want only one instance, we just instantiate the class once, and refer to that instance whenever we need it, end of story. We don’t need the compiler to slap us over the wrists if we do create multiple instances, because we never do so by mistake. If we do it, it’s because we have a reason. It’s because our initial assumption that only one instance was needed, turned out to be wrong!

So there you have it. A singleton combines two negative qualities. It takes the “you can never create a second instance of this class” constraint, which hardly ever makes sense, and even when it does, does not typically need to be enforced by the compiler, and combines it with a global object, giving us all the downsides of both!

Two wrongs don’t make a right. Not even if they were described as a good idea by some guys 15 years ago. They’re still no greater than the sum of their parts: two wrongs. One bad thing combined with another bad thing, creating a very bad thing.

Too many programmers rely heavily on singletons to solve a problem they never had. They never needed a compile-time guarantee that multiple instances of a class can never be created. They just needed one instance to be created.

Sometimes, we do need globals, yes. In those cases, make old-fashioned globals. Use static class members, or if the language allows it, global (non-member) objects. Or use the Monostate pattern, or whatever you feel is the cleanest solution. But remember that the problem you’re trying to solve is “enabling global access to this data”. No more, no less. You do not want a solution which sneaks completely unrelated constraints and limitations in through the back door.

And while I can’t personally think of many cases where this is true, you might also run into situations where it is truly necessary to prevent more than one instance of a class from ever existing. Again, I can’t think of what situation this might be, but I won’t rule out that it can occur. If it does, then enforce that constraint alone. But don’t go around providing global access to the object as well. Whatever specialized purpose your “one instance only” class serves, it’s highly unlikely that everyone should be allowed access to it. So don’t make it a global.

Most of the time, your classes should have neither of these attributes. Sometimes, rarely, they may need one of them. But the singleton pattern imbues the class with both properties, and that is just a plain bad idea.

But perhaps there’s a counter-argument that people seem to miss. If you use a lousy piece of software on a daily basis, you get used to it. You stop thinking about how it should be, and only consider how it is.

I think the first place I heard of the term “dogfooding” was on the Windows Mobile team blog. And let’s be honest, is Windows Mobile really a competitive product? Is it worth using? Perhaps in a vacuum. If all you know is Windows Mobile, then, well, it’s not too bad. But there’s an obvious reason why the product is struggling in the marketplace. Compared to everything else, it feels horrible to use.

Perhaps the recipe for fixing Windows Mobile would be less dogfooding. Windows Mobile developers shouldn’t be forced to use their own buggy, slow, in-development OS all the time on their phones. Perhaps they should be given iPhones and Blackberries. Perhaps some of them should even be given simple old-school non-smartphones. The ones that didn’t need to be rebooted, and didn’t “feature” load times for opening your contacts list, or to write a new SMS (text message). Perhaps they need to be shaken up a bit, and see what else a phone can feel like when you use it. Windows Mobile 6.5 might be better than WM6.0. But that’s not the competition they need to beat. They need to beat the iPhone, they need to beat Android, Blackberry and Symbian. So those are the products they should use at least as much as they use Windows Mobile.

The same may be true for Visual Studio. It’s great that the team uses Visual Studio 2010 internally as much as possible during development. But that also means that they get used to its performance issues. And it means they get used to the assumption that “this is what an IDE is like”.

Perhaps Visual Studio would be a better product if the team was forced to use Emacs, Vim and Eclipse. Or perhaps even Notepad and makefiles.

And how much better would TFS be, if the developers had used Git or Bazaar instead of dogfooding TFS during development?

Dogfooding has its advantages, certainly, but I don’t think it alone is a recipe for a good, competitive product. It leads to an incremental improvement over the previous version of your product, but it doesn’t take into account what else is happening in the world. It doesn’t give you the opportunity to question your basic assumptions¹. Sometimes, incremental improvement is not what your product needs.

Just a thought.

If I had to pinpoint one thing that marked the difference between a skilled and an unskilled C++ programmer, it would be “do they understand RAII”. Many people don’t, hence this post.

RAII is, apart from being badly named, one of those deceptively simple concepts that you think you understand when you first hear of it, think “well duh, that’s obvious”, and then proceed to write code as usual, because you just don’t see how widely applicable it is.

But let’s get the name out of the way first. RAII stands for “Resource Acquisition Is Initialization”. And if you’re not already familiar with the idiom, then this has told you nothing at all. If you did know about RAII in advance, then you can, when you stop and think about it, kind of see how the name relates to it… vaguely… sort of.

What it actually means is simple: Resources should be managed by classes. When the class is initialized, the resource is acquired (hence the name). When the class is destroyed, the resource is released. And the lifetime of the object should exactly match the desired lifetime of the resource. That sounds obvious, and many programmers will (assuming they’re working in a language that has classes), say that this is what they always do.

Often, C++ developers think this just means “smart pointers. Wrap your memory allocation in a boost::shared_ptr and you’re done”. I see that as one not-very-often used border case though, rather than a typical example of RAII. So let’s take a step back instead.

The key idea isthat any kind of resource, not just memory, but file handles, sockets, database connections, or even more abstract resources like loggers or profiling timers or textures, really any concept or process which has a lifetime, should be mapped to an object.

Unlike the typical object-oriented line of thought which goes that “everything must be an object, because then.… well, everything will be an object, and your code will be better”, here we actually have a concrete reason: We want to use the object to manage the lifetime of the resource.

When I allocate memory with new, I have to deallocate it again sooner or later, with delete. (Or in C, with malloc() and free() respectively). And I have to make sure that this is done. And I have to make sure that it is not done twice. And that the object is not accessed after this is done. There are a lot of constraints we have to obey, all related to the lifetime of the resource. And this is why unmanaged programs have a reputation of leaking memory left and right. If we allocate memory, and it is to be used by a dynamic number of objects or functions all referencing the same allocations, which of the users is responsible for deleting it? And how do we know when it is safe to delete, when no users remain?

Ironically, most managed languages have not solved the problem. They have added a garbage collector (which yes, is very useful for a wide number of reasons), but that only solves one specific instance of the problem. It takes care of avoiding memory leaks, but it doesn’t avoid resource leaks in general.

The garbage collector ensures that this code won’t leak memory:

void foo() {
  SomeObject* obj = new SomeObject();
  bar(obj);
}

where without a garbage collector, we’d (at least without RAII) have to write code such as

void foo() {
  SomeObject* obj = new SomeObject();
  try {
    bar(obj);
    delete obj;
  }
  catch(...){ delete obj; }
}

In the garbage collected case, we don’t know what bar does, and we don’t need to know. It doesn’t have to delete the object. And neither does the foo function. So we have successfully dodged the problem of managing the lifetime of memory allocations. We haven’t really solved the problem though. We still don’t have any good tools to manage the lifetime. We’re just guaranteed by the system that it’ll last long enough.

In C++, this effect can be approximated using some kind of smart pointer¹.

Smart pointers allow us to write code like this:

void foo() {
  boost::shared_ptr<SomeObject> ptr = new SomeObject();
  bar(ptr);
}

and be sure we won’t leak memory. Of course, this solution isn’t perfect — reference counting is much more expensive than a good garbage collector, and if we create cyclic references, the objects will never be deleted, as the reference counts never reach zero. It is a decent approximation, but nowhere near as good and reliable as the garbage collector in managed languages.

But the problem shows up again if we use another type of resource. What if we’d opened a database connection instead? We’d have to write code such as this: (The following Java-like pseudocode is copied almost verbatim from this StackOverflow.com answer, courtesy of Martin York.)

void writeToDb()
{
  Db db = new Db("DBDesciptionString");
  try
  {
    // Use the db object.
  }
  finally
  {
    db.close();
  }
}

(And of course it gets even worse if db.close() can throw exceptions. Then we have to catch that exception, just to avoid it propagating out from the finally clause if we reached finally because of an exception being thrown in the try clause.)

The resource management problem still exists. We still have to wrap the code in exception handling just to make sure that the connection is closed as soon as we’re done with it. And we have to do this at every use. And it gets complicated fast.

Of course, .NET makes this a bit simpler:

using (Db db = new Db("DbDescriptionString"))
{
  // use the database object.
}

But the onus is still on the user of the class to ensure it is closed correctly. There is no obvious way to encode into the Db class that “once we’re done with an object of this type, the connection must be closed immediately”.

And in C++, smart pointers are no longer suitable solutions, since the resource to be managed is no longer a pointer allocated with new.

Instead, a more basic flavor of RAII comes to the fore:

void someFunc()
{
    Db db("DBDesciptionString");
    // Use the db object.
} 

Yes, that’s all. When the db object goes out of scope, at the end of the function, its destructor is called. The destructor internally calls this->Close() for us, so we don’t need to do it! We just have to trust the scoping rules of C++, which guarantee that destructors are called on local variables when they go out of scope, and on class members when the class is destroyed.

So in a sense, the key idea in RAII is simply that “resources should behave sensibly”. They should get copied safely if an assignment is made (or otherwise, assignments should be prevented), they should be available if their owning object is successfully created (if it can’t create the resource, it should throw an exception, aborting the creation of the object), and when they are no longer used, they should be cleaned up.

The C++ standard library class template std::vector is a wonderful example of RAII in action. The resources being managed by a vector are memory (the array allocated internally to hold the objects being contained in the vector, as well as the objects themselves. When the vector is destroyed, every object it holds must be destroyed too, and the array in which they were placed must be deallocated.

In the following examples, assume that a function foo is passed a vector of MyClass objects by value. We don’t know how many, if any, objects are stored in it, but since we are passed a copy of the original vector, we take ownership of it. It exists only in the function foo, and must be destroyed afterwards.

void foo(std::vector<MyClass> vec) {
  ...
 //  when we get to the end of the function, all local variables, including vec, 
 // are automatically destroyed by having their destructors invoked.
 // So no matter how many MyClass objects were stored in the vector, it ensures that they too have their destructors called.
 // And the vector also deallocates its internal array, leaving neither of its resources alive at the end of the function
}

void foo(std::vector<MyClass> vec) {
  throw std::exception("Oops");
  // as above, vec is automatically destroyed when we leave the function,
  // regardless of *how* we leave it. Even if we leave it because an exception was thrown and not caught.
} 

void foo(std::vector<MyClass> vec) {
  // other is constructed as a copy of vec. std::vector ensures that both of vecs resources are copied as well
  std::vector<MyClass> other = vec;
  // we now have two vectors, each owning a dynamically allocated array and a number of MyClass objects
  // and again, at the end of the function, both are deallocated cleanly
} 

void foo(std::vector<MyClass> vec) {
  std::vector<MyClass> other; // a second, empty, vector

  // perform an assignment, setting vec to be an empty vector
  // std::vector makes sure that if you do this, the resources previously held by vec are cleanly released
  // before copies are made of the resources held by other
  vec = other;

  // and so when the function ends, the MyClass objects originally held by vec
  // have already been destroyed, so their destructors are *not* invoked now
} 

As the above shows, vec owns its resources, and manages them tightly. Whenever a change happens to vec, it reflects this by updating its owned resources. If it is destroyed, it destroys its owned resources. If it is copied, it copies the resources it owns. If it is assigned to hold something else, it first destroys its existing resources. And so on. Nothing you do can bring it “out of balance”. It just works. That is RAII. Smart pointers are just convenient adapters turning raw pointers into RAII objects. But RAII is much more than smart pointers.

It is the broad and general idea that resources should be mapped to objects, so that the object can not be created unless it succeeded in acquiring its resource, and it can not be destroyed without also releasing its resource. This effectively saves C++ programmers from having to worry about resource management.

Take an example that’s guaranteed to cause pain without the use of RAII: Handling exceptions being through halfway through constructors. Say you have a class with multiple members which are initialized in its constructor. After the first member has been initialized, but before all of them have been initialized, an exception is thrown. Let’s use the following contrived example:

class Foobar {
  Foo f;
  Bar b;
  MyClass c;

public:
  Foobar() : f(42), b("hello world), c('a') {}
};

unfortunately, b’s constructor throws an exception. How to handle this? We know that in C++, partially constructed objects do not automatically have their destructors called. when the construction is aborted.

And since we want to avoid any resource leaks, we require that the following must happen: – a must have its destructor called (because a was successfully initialized before the error occurrd) – b must release any resources it acquired in its constructor before it threw the exception – c must do nothing. Its construction was not yet begun when the error ocurred, so it would be an error to attempt any kind of cleanup of c. – The Foobar object (the object pointed to by the this pointer) must ensure that the above, and nothing else, happens, and it must do so without relying on its own destructor (which won’t be called, as construction did not successfully complete).

And of course, pretending that only b can throw an exception may be a simplification over the real world. Perhaps every member could throw one from its constructor. Care to write a Foobar constructor which takes all this into account, providing enough try/catch blocks to correctly catch every exception that might be thrown, and release exactly the resources that have been allocated until then, and nothing else? A tall order, and an open invitation for bugs. And of course, it’d lead to a huge, bloated and error-prone constructor. It’d also prevent us from using the initializer list. We’d have to perform some kind of “safe” non-throwing default construction of both a, b and c before entering the constructor body, where exception handling is possible, and from there, attempt to perform assignments to bring the three members into the desired state.

In pseudocode, the constructor might look something like this:

Foobar() {
  a = new Foo(42);
  try {
    b = new Bar("hello world");
  }
  catch {
    destroy a;
    throw;
  }
 try {
    c = new MyClass();
  }
  catch {
    destroy b;
    destroy a;
    throw;
  }
}

Note that all this complexity is only necessary because we want to handle several different resources. a, b and c all contain resources that must be attempted acquired, and properly released if this fails. If there’d been only one resource, the job would have been much simpler. There wouldn’t be any point at which some resources have been acquired, and others have not. If we succeeded in acquiring that one resource, there’d be no risk of errors occurring afterwards, so we wouldn’t need complex conditional cleanup code. And if we failed to acquire the one resource, there’d be nothing to clean up — after all, the resource was never acquired!

So to keep down the complexity, the only safe way to define a class is to make it own at most one resource. And this one-to-one mapping of resources to classes is exactly what RAII is all about. If a, b and c had all been RAII objects, then the above code would work. Regardless of which members could or couldn’t throw exceptions. According to the rules of C++, we know that in the above case,

• the Foobar destructor (this->Foobar::~Foobar() will not be called, as *this was not successfully constructed.
• the a destructor will be called, as this member was fully constructed at the time of the error.
• the b and c destructors will not be called, as these members were not fully constructed at the time of the error.

So assuming that b’s constructor takes care of releasing any resources successfully allocated when the error occurred (the number of which, as pointed out above, should ideally be zero), we’re actually home free! What happens is exactly what we listed earlier as our goal. a has its destructor called, c’s constructor was never run in the first place, so it doesn’t have to do anything, and *this doesn’t have to do anything special in its constructor. All of its members take care of their own resources, so the number of resources managed by *this is zero!

We don’t even need to write a destructor for Foobar now, if all its members are RAII objects. Whether the Foobar object is partially or fully constructed, its members take care of themselves. That is the power of RAII. Once a resource has been mapped to a class, we can use it as much as we like, and even in very complex situations, and never have to worry about the resource being leaked. It is managed by its wrapping RAII object, and the C++ lifetime and scope rules ensure that this wrapper object gets destroyed when it goes out of scope

First in line is Microsoft’s C++ compiler and IDE.

From you, what I’d like to see in 2010 is actually fairly simple (at least conceptually): rethink your IDE. The Visual Studio team as a whole is already doing this in a big way with VS10. I’m hoping you can find the time to reinvent the C++ IDE specifically as well.

For the past decade (except for the 5 years you wasted trying to eliminate native C++), you’ve been trying very hard to write the ultimate IDE for the wrong language. You’ve got something that works pretty well for C++ code anno 1993 or so. And which completely falls apart when used for more modern C++. Why do you persist in putting so many resources into making Intellisense better, when it still has no way to deal with a simple template function? Isn’t that a hint that you should rethink your approach? Modern C++ has quite a bit in common with dynamic languages. The type of a function parameter may not be known just by looking at the function definition. Often a full-fledged “interactive mode” as is common in dynamic languages, is desired, for example if we want to see what the actual type of some template parameter is. Or when instantiating template metaprograms, we may wish to step through them line by line at compile-time, rather than being limited to looking at the compiler errors — the metaprogramming equivalent of printf–debugging. What I’d like to see from the MSVC IDE in the coming years is an acceptance and support of modern C++ paradigms — generic programming, template metaprogramming and all the difficulties that implies. Don’t give me an IDE that tries to provide Intellisense for a program with a completely static structure. If you’re going to do Intellisense, make it able to handle the very flexible type system enabled by templates. take a leaf from the JavaScript support in your IDE, which supports intellisense even though the language is dynamic and types generally aren’t known until runtime. So to display type information in the IDE while the code is being written, they have to be clever. But they can do it.

In C++, the types aren’t known until compile-time, so from the IDE’s point of view, the problem is similar. To display type information while the code is being written (and before it is compiled), the IDE has to be clever. And at the moment, it isn’t. At the moment, Intellisense just gives up.

Let’s take a simple example. What should the IDE do about this function:

template <typename T>
typename T::return_type foo(T arg){
  bar(arg);
  return arg.baz();
}

If we play it by the book, and demand a “perfect” solution, there is nothing the IDE can do. It doesn’t know what T is, so it can’t help us with autocompletion, suggesting members after the dot, or anything else. But if we’re willing to think outside the box, and accept a success rate lower than 100%, there are several strategies the IDE could use to provide meaningful Intellisense information:

• we could look at the call sites. They must logically provide types that are valid in this context. We could find one call site, and provide Intellisense on the assumption that the type T is whatever was passed at that call site. That wouldn’t be 100% accurate in all cases, of course, but it would give us a type that works with the function, so it would be useful. It could even look at several call sites, and compute the union of the types used. If they all provide a frobnicate() method, then the IDE could assume that T inside the function foo always contains such a member.
• We could look at how the type is used in the function. It must have a copy constructor (because it is passed by value), it must have some nested type return_type, and it must have a no-arg baz member function, which returns something convertible to that type. And it must be convertible to whatever arguments bar expects. This probably isn’t a complete description of the type, but it would be enough to give us some limited Intellisense information at least. The compiler might be able to deduce some information about the type. We could even generate some kind of ad-hoc “concepts” implementation — perhaps not as extensive as that which was proposed in C++0x (and subsequently dropped), but a kind of helper datastructure that the IDE can attempt to map onto unknown template types.
• Or we could allow the user to specify an example of a valid parameter type, and then use that to generate Intellisense information from.

But an alternative approach (and these aren’t mutually exclusive) might be to reduce the reliance on Intellisense, which is essentially a static analysis tool. Perhaps a better approach would be to bring the “Immediate” pane up to date, and make it useful, not just during debugging, but while programming as well. Why can’t I through the intermediate window ask for the class std::vector<bool> to be instantiated, for example, so that I can inspect its structure? Perhaps I’m curious what its iterator type will resolve to, or perhaps I want to know the size of the class or other static information. Why can’t I just ask the IDE for this information? Again, modern C++ has a lot in common with dynamic languages. Very little information can be reliably extracted without compiling the code. So give me the tools for optionally and temporarily compiling bits and pieces.

When I write silly template metaprograms to compute the N’th prime number, and the result is wrong, why doesn’t MSVC provide a compile-time debugger? One which lets me step through the instantiation of this maze of templates, inspect the members of each, and find out where it went wrong, where it instantiated the wrong template, or where I forgot to write the specialization I intended.

In far too many ways, the C++ IDE really feels like a C IDE. Most of it doesn’t seem to know that there’s this new-fangled thing called “templates”, or that they change how people write code. The Immediate window or the debugger, do not recognize template parameter names. If I am debugging a function template <int I> void foo(), why can’t I get the debugger to tell me the value of I? It should be absolutely trivial to do. But the debugger can’t seem to do it. Intellisense can’t seem to do it. The Immediate pane can’t seem to do it. There’s a clear mismatch between the compiler, which is clearly a C++ compiler, and pretty much hasn’t bothered about the C side for close to a decade, and the IDE which still seems to be trying to be the perfect C IDE, completely disregarding every feature unique to C++.

I know you’re used to being told that you have one of the best IDE’s in existence. I beg to differ. You may have got one of the best C IDE’s, and your C# and VB IDE’s kick some serious butt. But your C++ IDE is essentially nonexistent. Your IDE does not support C++. It supports a marginally and conservatively extended C.

So far, I’ve dealt exclusively with the IDE issues, and that’s not a coincidence. On the whole, I’m quite happy with the MSVC compiler. The performance of generated code is good; you’re making great progress on C++0x support, and overall, you’ve got a compiler I’m happy with. Of course there are still a couple of areas where the lack of standards-conformance is embarassing (never mind the export keyword, I’m more bothered about two-phase name lookup and other relevant features), and there are some features I wish you’d borrow from GCC, but on the whole, and I wish you’d tighten up your warning messages a bit (some of them are nothing more than noise, or are impossible to avoid in “good” healthy code), I have relatively few serious complaints about the compiler. I do, however, have a few suggestions.

It seems to me that the source/header compilation mechanism could use a makeover. We can’t change the actual semantics (yet — hopefully the proposal for a module system for C++ gains traction), but the compiler can change how it actually processes the code. And yet, major compilers still process the source files in the exact same manner they did 20 years ago. Even though this is, on today’s machines, and with today’s huge codebases, ridiculously inefficient.

Ages ago, precompiled headers were invented, but I’m not really a fan of them. It’s a hackish solution which sometimes helps, but may also hurt, due to the tendency towards including everything in one single “blob” header. Even if that header is precompiled, it still means everything that includes it has to deal with these bloated monolithic symbol tables and other data structures. More importantly, it is a fragile solution, as the VC Team’s own blog shows.

But why can’t this mechanism be generalized? Why can’t the compiler process every header in isolation, build a complete parse tree of each one, and store those on disk? And then, when the header is included, rather than reading and parsing the header again, simply load this parse tree and merge it into the rest of the compilation unit. Of course, it is easy to come up with cases where the file may have to be parsed differently depending on where it is included, but in 99.9% of all cases, the inclusion mechanism is straightforward and simple: The header is typically not included in the middle of a class definition or from inside a namespace. It usually only reacts to a few fixed macros that may be defined before the header’s inclusion. So most of the time, the header could be precompiled in isolation and reused. And for the few cases where the changed state actually matters, where the header is included in the middle of a function definition or with no include guards or where a macro (say CreateWindow, or a similarly common name, cough cough) mangles the contents of the header, in those cases, the compiler can simply fall back to the traditional source code inclusion and subsequent compilation of the translation unit. Even if these precompilation passes aren’t stored to disk in the manner of precompiled headers, they could still be kept in memory, and reused between translation units during a build. If N .cpp files all include a certain header, it would allow that header to be compiled once, rather than N times.

Once again, we have something that feels like a leftover from C. In C, headers were mostly forward declarations and little actual code, so naive processing of headers worked fairly efficiently. in C++, it is getting more and more common to put huge amounts of code in headers, which means that the naive compilation strategy traditionally used for C becomes ridiculously slow and inefficient. Creating a truly general replacement strategy is nearly impossible, true, but it seems like it’d be possible to create a heuristic that’d enable more efficient processing of header files 99% of the time, and which could then fall back to the traditional method of copy/pasting headers into the translation unit for the last percent of cases.

And why does every translation unit have to read every file every time? Can’t their contents be kept in memory, at least for a short time? Those hundreds or thousands of file accesses are painfully slow. Windows already exposes APIs for monitoring file changes, so it should be fairly simple to determine when a source file has been modified, and only then flush it from memory.

And of course, everyone’s favorite nitpick: Why is windows.h so absolutely horrible? Why does it have to be one monolithic header which gives us everything Windows has to offer? Why doesn’t it compile as standard C++? Why does it include so many other headers (as above, slowing down compilation)? Why does it pollute the global namespace with macros for ridiculously common names?

Well, it does, and it’d be silly to expect this to change, due to backwards compatibility concerns. But why then, is there not a windows.hpp or similar? Why isn’t there a separate cleaned-up, C++-compatible header? One which uses function overloading instead of macros, for example? Or which just defines simple forwarding functions instead of macros? One which compiles even with the non-standard language extensions disabled? Or why isn’t there a set of these headers, allowing us to access the bits of the Windows API we’re interested in, without having to include *everything?

In short, I think the MSVC IDE (and in some cases the compiler too) is in desperate need of a rethink. Out with those 12-year-old project wizards, which create complex predefined project structures accumulating every bad practice and unexpected project setting in one place. I’ve lost count of how many beginners I’ve seen choke because their tiny little projects automatically get a precompiled headers thrown in for absolutely no reason. Out with the idea that C++ can best be presented like C#, as a static language where every piece of code can be understood in isolation. Instead, give us an IDE that treats C++ as a more dynamic language, where many types of information are just not available until the program has been compiled, and which embraces the unique features of C++ — one which supports and encourages use of templates, one which accepts that in modern C++, most code ends up in header files, and these header files become expensive to compile, and so are an area ripe for optimization. An IDE which treats C++ compilation as an interactive process, where template instantiation can be stepped through and inspected at each stage, and where interactive queries can be made statically or during debugging to inspect not just data, but also types.

Another addition that would really boost the usefulness of MSVC would be to provide facilities for template metaprogramming in unit tests: For example, it is common to use metaprograms to force compilation failures if a template is instantiated with a specific type. But how do we test that this works as intended? Give us the hooks and language extensions necessary to specify that “this function is expected to fail to compile, and if it does, that’s not an error, just remove the function and compile the remainder of the file”. Again, consider compilation process a part of the language — it is something that must be inspected and debugged, and for which we may wish to write tests.

void my_testcase() __declspec(wontcompile){
  // perhaps we want to ensure that the template can not be instantiated with a reference,
  // so we expect this test to fail
  frobnicator<int&> f; 
}

// if the above test fails to compile (as it should), the compiler should simply ignore it, and proceed to compile the other tests, rather than aborting
void next_testcase() {... } 

Target your IDE at Modern C++, rather than C with classes. Impress the world by being the first IDE to even think about this. Embrace, and provide support for, the changes that have happened in the C++ language, in best practices and in the mindset of the C++ community. Accept that yes, headers are ridiculously heavy these days, and blindly recompiling them for every translation unit doesn’t scale. Accept that the C++ language needs IDE support to inspect what happens in our compile-time metaprograms as well as at runtime. And face up to the fact that traditional intellisense is a lost cause. There is no way to statically produce all the information we expect from intellisense. Some can be improvised by various heuristics, or as in the template function case, by assuming some suitable dummy value for the function’s template parameters, but others may be nearly impossible to provide until the program has been compiled. So perhaps you need to think beyond Intellisense to provide this information to the programmer. Perhaps an “interactive mode” would be more suitable. If the IDE can’t provide the information I need automatically, it could at least allow me to query for the information. Perhaps it can’t tell me anything about the template type T, but why can’t I tell it to assume that T is a std::wstring, and provide information based on this assumption. Or something else entirely. You already have a pretty good C++ compiler. It’s time to start working on a C++ IDE, and call it a day on the C IDE you’ve been polishing until now.

So dear MSVC team, in case you can’t think of anything useful to do with your time in the year 2010 (as if… I know you’ve got C++0x support to work on, and that’s infintely more important to me than IDE improvements), here’s a new year’s resolution for you: Amaze the world, by showing what a C++ IDE should work like. Reinvent the role of the C++ IDE, instead of trying to force the C# or C IDE to work for C++ as well.

Let’s make it clear though, that the following will have very little practical use. We’re not just into “it doesn’t make a measurable difference” territory, but also deep into “the compiler will do this for you”. So please, don’t try to apply these “optimizations” to your real-world code to save a clock cycle.

This is merely intended as a thought experiment, illustrating some of the factors that makes performance so difficult to predict. And now, with that disclaimer in place, let’s get on with it:

The problem

The “problem” I came up with was the evaluation of x+x+x+x. This was the simplest snippet of code I could think of for which optimization is possible. For the sake of this discussion, let us assume that x is an integer.

A naive compiler will evaluate this code as ((x+x)+x)+x. In other words, it will evaluate one addition, feed that result to the second addition, and then finally feed the result of that to the third addition.

Optimization #1

The optimization I suggested was to evaluate it as (x+x)+(x+x) instead. And why is this faster? A modern CPU is superscalar — that is, it is able to execute multiple instructions every clock cycle. Depending on the CPU model, it can probably execute three or four instructions belonging from the same thread every cycle.

So where the original version would take three times the duration of an add instruction to execute, my optimization can be done in two times the duration: Both the initial subexpressions can be evaluated in parallel. And so, after only the duration of one add instruction, we’ve got the result of two of the additions, and can perform the third and final one. So in this very simple case, we actually reduced the run time by 33%. Not bad, eh?

Optimization #2

My friend then asked if x*4 would be an optimization as well. And now it gets a bit more interesting.

First, of course, x*4 is just a single multiplication. Is that faster than three additions? Is it faster than two additions (which is the time it’d take for my “optimized” version to run)?

That depends on the speed of a multiplication instruction. On common CPU’s, a moment’s research tells us that add has a latency of 1 cycle, and mul has a latency of 3 cycles.¹, so the multiplication takes as long as the original unoptimized version.

Evaluation

So what does this mean? That at a glance, optimization #1 is faster than #2, certainly. #1 yields a result after two clock cycles, where #2 takes a whopping three cycles.

But there are other factors at play. Sometimes the multiplication version may be more efficient. The CPU has a limited number of execution units. It can also only decode a limited number of instructions at a time.

The version using addition requires three instructions to be decoded, and uses two execution units during the first cycle, and one unit in the second. All in all, we’re occupying three “execution-unit cycles”. The version using multiplication does take three cycles, but because modern CPU’s are pipelined, it only occupies the execution unit during the first cycle. In the second cycle, the execution unit is able to begin on a new instruction, while continuing to process the mul instruction. So this version only requires one “execution-unit cycle”. In other words, we’ll free up other execution units so they can execute other instructions. We’re also freeing the front-end from having to decode three instructions.

So we now know that:

• If we need the result as soon as possible, the optimized add version will be more efficient because it finishes sooner.
• But if we need to execute a lot of other instructions as well, the mul version will be more efficient because it uses fewer hardware resources on the CPU

What if we have a lot of instructions we want to execute and we need the result soon? Or if we only have these instructions to execute, and we don’t care about when we’ll get the result (perhaps the next operation is to add the result to that of an ongoing division, which is very slow, so it won’t matter if we take 2, 3 or 15 cycles to get ready)? Hard to say. Either one may be preferable.

Of course on x86 CPUs we also have to take the variable instruction length into account. How many bytes does a mul instruction take? What about three adds? That affects both how much data has to be read from memory and how much space will be taken up in CPU cache, and so that should be taken into account as well.

So what can we learn from this? Mainly that performance is nontrivial. Never assume that you can tell whether some code is “fast” or “slow”. And be especially careful with assumptions about how it can be improved. It is very possible that your “optimization” will actually run slower.

Whenever you optimize code, do as the pros: measure, measure and measure. Measure the speed of the original code. Measure the result of the optimized code. Be careful with the many ways in which your measurement can be invalidated (by the compiler optimizing away the code you wanted to test, or by the CPU cache changing the result in your test case from what you’d expect in the real world by caching — or not caching — the data you’re operating on).

And when performing low-level optimizations, another vital piece of advice is to understand the hardware. Know which instructions are being executed, know the cost of instructions on the relevant hardware, and know what other tricks the hardware uses (Your CPU is probably superscalar and pipelined, and processes instructions out of order. It probably also has a cache of a certain size, with a specific cache line size, and a certain associativity. It has a fixed number of execution units, a known pipeline length and so on. And while we’re at it, the memory subsystem matters too. How long does it take to access RAM? How can the CPU reorder reads and writes? What is its policy for writes? When are they pushed from cache to RAM? If you want to optimize your code on the instruction level, you need to know your CPU. Even the simplest code is affected by dozens such factors, any of which might make a difference.

Well, my test case for this feature now takes ages to run. As I mentioned previously, a simple transaction modifying two integer variables under heavy contention can pull off almost two million transactions per second on my laptop.

My new test, in which each thread takes four variables and alternates between modifying two of them and reading the other two, runs perhaps ten thousand (!) times slower.

Of course I have several leads on how to fix this. The problem is largely all the performance-related “extras” I’ve been leaving out. For example, if a transaction fails to acquire a variable it needs, it simply aborts and immediately retries. In many cases, a better approach would be to block the thread, waiting for that variable to actually become available.

There are several other cases where I have a similar problem: I have to choose between delaying the thread for a moment with sleep() before attempting to continue, blocking it until some condition is true, or aborting the transaction entirely and starting over from scratch. At the moment, I generally just pick the easiest solutions (typically abort, and occasionally call sleep() a few times before we resort to that. Again, implementing some actual meaningful policies here would make a big difference. And tweaking these policies should help still more.

Another problem is that currently, I do not enforce a consistent global order when acquiring objects during a commit. This means I risk livelocks, again causing excessive rollbacks when multiple threads are competing over access to the same variables.

So I’m still optimistic. It should be possible to get performance back on track. But man, it’s depressing watching performance plummet like this.

Edit
And an update. After poking around a bit, it turned out that most of the time was being spent sleeping. When a transaction attempts to commit, if it can not acquire all the all the variables it needs, it retries a few times with a short delay (a couple of milliseconds) in between. If it doesn’t succeed after a few tries, it rolls back the entire transaction and starts over.

It turned out that these few, short sleep() calls brought CPU utilization down to something like 0.01%, and totally destroyed performance. Simply turning the sleep() call into a no-op brought me back to something more or less reasonable. I still need to improve on the above shortcomings, but now at least I can run my tests in less than an hour.

In the following, I’ll show a slightly modified version of one of my test cases. It shows how to call and use my library, from the user’s point of view. The test spawns a number of threads, which each wait on a barrier (because if one thread was allowed to run while another was being constructed, I’d get fewer concurrent transactions, and my test would be less likely to uncover race conditions), and then perform a fixed number of transactions. In each transaction, two transactional variables are opened for writing, one is decremented and the other incremented. If the sum of these variables is nonzero in any iteration, the thread registers a failure.

And if, after all the threads have terminated, the value of each of these variables is not what was expected, a failure is registered as well.

So from a testing point of view, there should be plenty of opportunity for things to go wrong. Just a single small race condition somewhere, and one of the many millions of reads would be inconsistent and the test would fail.

#include <stm.hpp> // my STM library

#include <boost/test/unit_test.hpp> // Boost.Test is used to supply a unit-testing framework
#include <boost/thread.hpp> // Boost.Thread is used as a threading API

// define the number of threads to run, and the number of iterations for each
enum { thread_count = 8, iterations = 200000 }; 

// The following are transactional variables. The shared template ensures that the contained value
// can only be accessed as part of a transaction, and provides the necessary metadata
// for checking validity and consistency
// Two such integers are created, both initialized to zero
stm::shared<int> val1(0);
stm::shared<int> val2(0); 

BOOST_AUTO_TEST_SUITE( threads ) // define a test suite named "threads"

// this function defines the body of our transaction. 
// We're passed a transaction, which can be used to open any "shared" variables
bool tx_func(stm::transaction& tx){
    // open both variables for writing
    int& a = val1.open_rw(tx);
    int& b = val2.open_rw(tx);

    // modify the variables freely
    --a;
    ++b;

    return a + b == 0; // Our transaction returns a bool. Other return types (or void) are also supported
}

// this class defines a thread. operator() is called as the thread's entry point
struct thread_functor{
    // In the constructor, the thread object is given a barrier it can synchronize on,
    // and a reference where it can write the its result (success/failure)
    thread_functor(boost::barrier& bar, int& res) : bar(bar), res(res) {}

    void operator()(){
        // when the thread is first created, we wait for the barrier
        // This ensures that no transactions are running until all threads have been constructed
        bar.wait(); 
        for (int i = 0; i < iterations; ++i){
            // for each iteration, pass our transaction function to the "atomic" function, which executes it atomically.
            // To get a non-void return type, we have to specify the template parameter explicitly 
            // (this can be avoided in C++0x using the return_of template to deduce the return type implicitly)

            // depending on the return value of the transaction, write success or failure back
            res = (res != 0) && stm::atomic<bool>(tx_func) ? 1 : 0;
        }
    }

    boost::barrier& bar;
    int& res;
};

// another transaction, to be executed after our helper threads terminate, 
// to verify that the right number of modifications have occurred
// note that here variables are opened for reading only
void verify(stm::transaction& tx) {
    const int& a = val1.open_r(tx);
    const int& b = val2.open_r(tx);

    BOOST_CHECK_EQUAL(-a, thread_count * iterations);
    BOOST_CHECK_EQUAL(b, thread_count * iterations);
}

// finally, we get to our test case itself
BOOST_AUTO_TEST_CASE ( short_concurrent_transactions )
{
    boost::barrier bar(thread_count);
    boost::thread_group gr;
    int res[thread_count]; // array of results
    // set all the results to an initial true/1 value (since each iteration "and"'s it together with the current result
    std::fill(res, res+thread_count, 1); 

    for (int i = 0; i < thread_count; ++i){
        gr.create_thread(thread_functor(bar, res[i])); // create the threads, passing the necessary parameters to each
    }

    gr.join_all(); // wait for all threads to terminate

    // verify that each thread return success
    for (int i = 0; i < thread_count; ++i){
        BOOST_CHECK_EQUAL(res[i], 1);
    }

    // run a final transaction to access both variables and check their final values
    stm::atomic(verify);
}

BOOST_AUTO_TEST_SUITE_END()

In the above, I used a function object to represent threads, and a regular function to represent transactions. Of course in both cases, either would work — a function object would potentially be more efficient as it is easier for the compiler to inline, but I used a function for brevity.

In C++0x, of course, lambdas could also have been used in both cases.

One of my design goals has been to make basic usage as simple and intuitive as possible, and I think I’ve succeeded so far. Any C++ programmer who is familiar with the STL algorithms or the Boost libraries, should find my library’s interface very straightforward. Note especially that all the transaction “magic”, of verifying validity and retrying transactions as needed, is completely invisible to the user. You simply define a function expressing what your transaction should do, and pass it to the atomic function.

In its current version, this test is able to execute around 1,800,000 transactions per second on my Core Duo 2GHz laptop. (Of course, with transactions as small as these, opening only two variables each, performance is a lot better than it would be in real-world transactions.

So that’s it for now. Of course I’ve got a few more user-facing features in the pipeline¹, and a lot of backend changes, but the basic functionality is there, and I’m pretty happy with it so far.