The result is that a lot of people now have sensitive personal information floating around in public. An example of this (found via ArsTechnica) is this woman, who starts her post like this:

I use my private Gmail account to email my boyfriend and my mother.

There’s a BIG drop-off between them and my other “most frequent” contacts.

You know who my third most frequent contact is?

My abusive ex-husband.

Which is why it’s SO EXCITING, Google, that you AUTOMATICALLY allowed all my most frequent contacts access to my Reader, including all the comments I’ve made on Reader items, usually shared with my boyfriend, who I had NO REASON to hide my current location or workplace from, and never did.

Ouch.

Others, with less at stake personally, are also pissed:

See, I love the idea of neat new tech innovations that lead to streamlined communication, real-time updating, in-line video and photo posting, and supersimple friend and contact integration. I do not, however, like a product that bursts through my door like a tornado and opts me in to wanton in-box clutter and spam (or, more precisely, bacn) publicly reveals my personal contact list without asking me, threatens to broadcast my e-mail address anytime someone wants to @ me in a Buzz, and even appears to grab photos off my Android phone that I’ve never uploaded.

or this one

So…yeah, I guess I’m on Google Buzz. It’s linked to my Picasa and WordPress accounts, so you can follow everything I do. Cause that’s not creepy or anything. The best part is that the defaults for everything are public, and you end up broadcasting to a bunch of random people unless you sit down and sort through. I’m expecting this to backfire for a bunch of people, and not just eventually but almost immediately. It might not be a bad idea to start a betting pool on when the first child porn charges are filed as some highschool student accidentally sends herself to the entire school.

I could go on, but I really don’t want this to turn into some kind of link farm.

I’m not personally affected by this. I do have a GMail account, and yes, they opted me in to Buzz, but the account contains no personal information whatsoever, and no personal emails. I use it exclusively as a dumping ground for spam, and form mails I don’t want cluttering up my real email inbox. I’ve never even sent an email from the account.

I use the Google search engine, but I am not signed in to it, and have never created a profile or a customized homepage on it. I’m sure they could still identify me just by examining cookies or my IP address, but at least they’d have to work for it. And it’s not like my Google searches are state secrets anyway. As long as people are not able to search for my name and bring up a list of everything I’ve searched for, I’m satisfied.

I also use Google Analytics for this blog. I feel OK about that because this blog is already my public face on the internet. Google already knows a lot about it simply by indexing it for their search engine. I have no problem with them generating statistics on where my visitors come from, as long as they make the information available to me too. The only sensitive information associated with this blog is my login password, and I’m pretty sure Google doesn’t have that. And they’re not getting it, even if they launched a GPassword service tomorrow.

I use the Wordpress software, but not hosted on Wordpress.com. I don’t use Picasa or Google Reader. I don’t use Google Documents.

So all in all, yes, Google certainly knows a lot of fragments of information about me. Google searches can turn up quite a bit, they can collect a few more bits and pieces through cookies when I use their search engine, and they have a lot of statistics on who reads my blog. But they can’t read my emails. They don’t have any really sensitive information about me. Nothing related to my work, personal life or studies is tied to Google.

And this brings us to the point of this post:

Don’t blame Buzz, blame GMail

A lot of people are furious at Google for the mixture of incompetence and indifference towards users’ privacy with which Buzz was launched, and while that might be justified, it is missing a fundamental point.

Buzz is just doing what Google does best, what they’ve always done, and what they should be doing. Here’s what Google’s own website has to say on the company’s mission:

Google’s mission: to organize the world’s information and make it universally accessible and useful

Google is dedicated to making information universally accessible. For a lot of information, that’s a good thing. Their search engine turned the internet upside down — for the first time ever, users were able to actually find the information they needed. Google is good at this, and we’ve benefited hugely from it.

And social networking is right up Google’s alley as well: Social networking is all about making information about you and me accessible to the world in an organized manner. A lot of Facebook’s popularity relies on their ability to analyze our existing relations, friendships and networks, and use this to suggest new friends. My Twitter would be useless if I couldn’t follow the people I wanted to keep up with, and if others couldn’t find my tweets through searches. Buzz is simply more of the same, and there is nothing wrong with that. It’s another social networking service, and Google is exactly the right company to do something like this. No one is better at organizing information and telling us exactly what we want to know.

The problem is that another of their services is not so well suited for the company. Email is something almost everyone considers personal and private. Even the US government, in its desperate war on people who wear turbans, speak funny and pray to Allah, has only given itself permission to sniff the subject lines of people’s mails sent over GMail. This is considered the equivalent of reading the envelope, without opening it and looking at the letter inside. Because that letter is personal. And so are the bodies of our emails.

But if we consider our emails to be sensitive personal information, then why do so many people entrust them to a company whose stated mission is “to make the world’s information universally accessible”?

A company like that should never be entrusted with our sensitive information.

Facebook has made some major blunders regarding privacy, but their mission seems to be something like “can’t we just all get along”. In Facebook’s perfect world, everyone are friends with everyone else. This doesn’t excuse their privacy issues, but at least it tells us that they’re not directly opposed to the idea of privacy. They’re just clumsy and don’t think things through.

Google, however, is different. In the perfect Google world, privacy does not exist. In Google’s dream world, I could go take a look at Bill Gates’ emails or Steve Jobs’ search history. or Bono’s shopping list. It is information. It should be made available to the world.

So no, there’s nothing wrong with Google Buzz. It should absolutely broadcast everything Google knows about us to the world. The problem is that Google has been given sensitive information in the first place. Google shouldn’t know anything about us that can’t safely be published through Buzz. If GMail had never existed, Google would not know that the woman in the first example has received emails from her abusive ex-husband, and so they couldn’t have caused her any problems. The only things Buzz would have known about us would be what we told it.

Imagine if Twitter or Facebook had been built by Google, based on their search engine and their ability to categorize and organize information. That is what Buzz could potentially become, and that’d be nothing short of amazing. At least as long as we all take care to keep our emails and other sensitive information far away from Google.

Don’t opt out of Buzz because of privacy concerns. Opt out of GMail instead. Expect every new service Google launches to do as Buzz. Their mission is to make all information available to the world, and they’re going to keep trying. You’re fighting a losing battle. You can keep opting out of their services till the cows come home. It’s always a temporary solution at best. Instead, fix the root issue: Make sure Google is not given any sensitive information about you in the first place.

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

But then again, neither is the “service” known as Games for Windows Live we PC gamers are being forced to swallow. So far, you guys have done an amazing job trying to eliminate the inconvenience known as PC gaming. You’ve done more than I’d thought possible to make it as painful as humanly possible. The mere presence of your logo is enough to make every PC gamer I know want to go have a lie down.

GFWL isn’t just the infamous polished turd. Partly because it is in no way polished, but mainly because it is not just a turd, which is a passive object that, while smelly, can be easily walked around and simply avoided, but a turd-being-thrown-in-your-face, an entity which actively tries to ruin your day. Most bad PC software can simply be avoided — we just choose not to use it — no such luck with GfWL. We don’t have a choice in the matter.

Here is a short, and incomplete, list of what you need to fix to even reach neutral ground. Fixing these atrocities is enough to nearly make your service tolerable. To actually make it an asset, something that enhances the value of the PC platform, you have to reach far far beyond this. But just making it less nauseating to use would be a wonderful start, and should mean that you’ll have your hands full for the entire year.

But enough ranting. On with the list:

• Fix the friend list. When I want to invite a friend to a game, the correct approach is: 1) Hit a key to pull up the friends list. 2) Click on my friend. 3) click “invite to game”. You may have noted that this is what Steam does, and has done for years. Inviting a friend to a game takes perhaps one second there. Now, since it’s pretty obvious none of you have ever attempted to do this in GFWL, I should probably explain how it works (or fails to work) there: First, you hit a key which conflicts with every game that has a chat box: home, the key which is normally used to move the caret to the beginning of the line/text input. Then you wait for the screen to go dim and the slow and painful animation of the GWFL client unfolding. You now get to some kind of “main menu”, from which you can do absolutely nothing. Here, you click on the “Friends” button, and again, wait for the animation to finish. Now you get your friends list, from which you may.….. click on a friend, and wait for yet another animation to finish. You may then click “Invite”, and you get, once the next animation has finished, a goddamn email interface! Then you click send, and the request is sent off, in a semi-random language (see one of the following points). Or, of course, you may sometimes go directly to the email interface, from where you can either 1) fill out your friends name from memory, or 2) click the “to” field to bring up (slowly, after another animation), a list of every goddamned person you’ve ever played a game with. In short: When I want to invite a friend to a game, I do not want to send an email. I don’t want to see the list of several hundred jerks whom I was matched against in earlier games. I want to see a list of my friends, the ones I have personally indicated an interest in play with by adding them to my friends list, click on the right one, and click “invite”.
• Fix the language setting. I don’t want to get game invites in Norwegian just because someone from Norway is hosting the game (as pointed out above, I don’t need an actual message from them at all! Just give me a choice of clicking “accept/decline invitation, not an actual email message). I also want to be able to set the language myself. Yes, I use Danish regional settings, but that’s because I want the time and date formatted that way, not because I want to read your dodgy Danish translations in the GFWL interface. And despite those regional settings, I’m running an English copy of Windows, for precisely this reason: My english is good enough that I prefer your products in their original language, sidestepping all the inevitable translation issues. Said Norwegian friend literally didn’t understand what GFWL was trying to tell him when he first logged in. The so-called translation was unintelligible. Of course, another Norwegian friend, and god knows why, as they’ve compared all regional settings they could find and couldn’t find any meaningful difference, got GFWL in english. Why? I’ve gotten Danish on a few occasions, but luckily, so far, it has mostly been in English. But even so, I want 1) to be in control of the language to use, and 2) proper translations if you’re going to translate. And 3) as long as you don’t allow me to choose the language, I at least want it documented how GFWL determines which language to use. Then I can change that particular setting in Windows, and get the language I actually wanted to begin with.
• Make the GFW logo (the non-Live one, to begin with) synonymous with actual quality. Gears of War, one of your flagship titles was so badly ported it’s scary. Not only did the installer take the better part of two hours to complete, it was also buggy and required a patch to even launch the game. Which then didn’t work on 3 out of the 4 computers I’ve tried it on. This may surprise you, but to enforce a minimum quality across PC games, it is not enough to design a new logo, you also have to verify that the games that get the logo actually do behave sanely and actually work on a PC. You have to ensure not just that the game works with a 360 controller, but that the game works better than those without the logo.
• The services you provide to games tied to your service should be better than what they’d have made themselves otherwise. Dawn of War 2’s matchmaking is an atrocity. It matches new players against the most hardcore, it frequently takes minutes to find a match even in Last Stand games where there’s only one team and it was full to begin with, so the total number of players it has to find is a big fat zero. And NAT errors are frighteningly common. More so than Relic’s previous game, Company of Heroes. Or Dawn of War before it. Relic’s own homebrewed matchmaking and NAT-traversal code worked better than that being made available by you for the betterment of PC gaming.
• Make it possible to navigate and use your Marketplace.
• Listen to community feedback. When high-profile games journalists have nothing positive to say about your service, you have a problem. When “ordinary” gamers feel just as bad about it, you have a big problem. Perhaps a good start would be to provide somewhere for users to leave feedback. Put it on Microsoft Connect. Or perhaps open a blog for GFWL specifically (rather than extending whatever XBL-related blogs you already have to also cover GFWL). Perhaps just add a “Contact” or “Feedback” link on the GFWL website, even. I’ve spent far more time than is reasonable looking for a place to provide feedback, and failed to find anything.
• Listen to developer feedback. Even if you manage to convince games journalists and actual gamers of the benefits of your service, you need to get developers on board as well.
• Make the service for PC users. Showing us images of the 360 controller is just a bad joke. Yes, we may have bought one of those, and it may even be connected to our PC, but the default mode of control is mouse and keyboard. Deal with it. Telling us to press the A button is not helpful. Showing an icon of the 360 controller in the main GFWL bar only serves to make it look like you ported the service straight from the XBox, without changing a line of code.
• And finally, your service has to provide us with some kind of value. What exactly do I gain from one of my games being GFWL-enabled that I wouldn’t have gotten if it was 1) Steam-enabled instead, or 2) old-fashioned not-tied-to-any-thirdparty-online-service?

So dear Games For Windows Live team… Is 2010 going to be the year when you finally cancel out the pain caused by your service? I’m not asking for miracles, I don’t want you to makeanything that adds positive value — I just want you to stop subtracting value from the product that uses your service. Please? Is it at least going to be the year when you start soliciting feedback? Open a blog? Open a connection on MS Connect? Provide a feedback email address? A Twitter account? Anything that might show that you’re not just a bunch of monkeys banging blindly on keyboards.

Well, like I said, harsh, but sometimes, the truth hurts. And it is nothing compared to how much your product currently hurts PC gamers.

So please, tell me that when 2011 rolls around, I’ll be able to write a more upbeat post about my hopes for you in the following year.

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.

I don’t know about you, but I had a blast this last year. New (awesome) apartment, started on my thesis, launched this blog, and just generally had a good time.

So how to follow it up? What can 2010 do to beat this?

Rather than coming up with a whole bunch of new year’s resolutions for myself, I thought it might be more interesting to reverse the process — and say what I’d like to see others do in the coming year.

Throughout the year, I’ve encountered a lot of software products that, for one reason or another, I’d like to see improve. Perhaps they simply suck currently, and desperately need to be fixed — or perhaps they’re already so good that I’m happy to use them, but I can think of further improvements that’d really make the “best in class”.

So for the next couple of days, I’ll post my thoughts on what I’d like to see from a few of these products during the coming year.

Hope you have a great new year’s eve! See you next year.

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.

However, a few things have been bothering me about it.

When I first signed up, I did a bit of research, and found out that you can use your own domain as your OpenID. You simply enter the following in a <head> of a HTML page you control:

<link rel="openid.server" href="http://myopenidprovider" />
<link rel="openid.delegate" href="http://myopenid-at-that-provider/" />

And the URI of that HTML page can now be used as your OpenID. It will forward authentication requests to the specified provider. This gave me a nice clean URI to use as my OpenID, and as a bonus, it meant that I could change my OpenID provider and keep my ID, just by editing this HTML.

Of course, I quickly found out there was a downside as well. When I created this blog, I placed it in http://jalf.dk/blog. I figured I could easily add a redirect from http://jalf.dk and so it wouldn’t matter in the long run.

When I tried adding this redirect, I realized that this of course would also redirect any OpenID requests. My OpenID provider would then see a login attempt from http://jalf.dk/blog instead, and all hell would break loose.

So I removed the redirect, and instead placed this message in http://jalf.dk/ along with the OpenID <link> tags:

Please go here for my blog. Sorry for the lack of a proper redirect.

Not very elegant, but it worked. OpenID requests were handled correctly, and readers of my blog could follow the link, or just bookmark /blog in the first place.

Today, a friend asked me why I didn’t have a redirect, and I explained the above problem. I didn’t think about it any further until half an hour ago, when I realized that Facebook can be tied to an OpenID account. As I said before, the more services I can log in to with my OpenID, the better, so I attempted to add my OpenID… And got a nasty error message telling me that my OpenID only supported version 1.1, and Facebook required 2.0.

Geez, I hadn’t even realized there were multiple versions.

So I went hunting for a solution. And it turned out to be pretty simple, and have the nice side effect of solving the redirection problem as well!

It turns out that the <link> tags embedded in HTML only work for OpenID 1.0 and 1.1. For 2.0, you have to provide a YADIS XML file.

Unfortunately, there seems to be very few examples online of what this file should look like. I did find a nice example of using a YADIS file for OpenID 1.0 here, which got me started. The Wikipedia article on YADIS held another example, but again only with OpenID 1.0. However, it also shows how to specify LID 2.0, so while I have no clue what LID is for, at least it gave a hint of how to support multiple versions.

Finally, diving into the specification for OpenID 2.0, I discovered the correct URI to specify as <Type> in the YADIS file: http://specs.openid.net/auth/2.0. Of course they just had to change the URI format between versions 1.1 and 2.0. Nothing is ever that easy.

But with this, the last piece fell into place. I created an openid.xml file looking like this:

< ?xml version="1.0" encoding="UTF-8"?>
<xrds:XRDS xmlns:xrds="xri://$xrds" xmlns="xri://$xrd*($v*2.0)"
xmlns:openid="http://openid.net/xmlns/1.0">
  <XRD>
    <Service priority="50">
      <Type>http://specs.openid.net/auth/2.0/signon</Type>
      <URI>http://myopenidprovider</URI>
      <openid:Delegate>http://myopenid-at-that-provider/</openid:Delegate>
    </Service>
    <Service priority="20">
      <Type>http://openid.net/signon/1.1</Type>
      <URI>http://myopenidprovider</URI>
      <openid:Delegate>http://myopenid-at-that-provider/</openid:Delegate>
    </Service>
    <Service priority="10">
      <Type>http://openid.net/signon/1.0</Type>
      <URI>http://myopenidprovider</URI>
      <openid:Delegate>http://myopenid-at-that-provider/</openid:Delegate>
    </Service>
  </XRD>
</xrds:XRDS>

and using the PHP snippet from paulisageek,

< ?php
if (strpos($_SERVER['HTTP_ACCEPT'], "application/xrds+xml") !== FALSE) {
  header("Content-Type: application/xrds+xml");
  echo file_get_contents("openid.xml");
}
else {
  header("Location: http://jalf.dk/blog");
}
?>

I now have:

• The same nice, short, easy-to-remember OpenID URI I always had
• My blog accessible form http://jalf.dk
• My Facebook account linked to my OpenID
• Support for OpenID version 2.0

All in all, I’m happy. And now that I’ve documented the process, perhaps the next person who runs into this problem may be a bit happier too.

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.