In the C++ bag of tricks: scoped locks

In my pet project XIOSim, I find myself using a lot of locks for short periods of time. No huge surprise -- XIOSim is a fairly large project with many threads that scales somewhat well on multicores -- keeping locks short and cheap is definitely one way to do that. Unfortunately, it leads to a lot of code that looks like this:

lk_lock(lk_var);
    var++; /* do something protected with var */
lk_unlock(lk_var);

That's a lot of boilerplate for something simple. I was getting annoyed at having to type this every single time, plus it makes code look cluttered and a tad ugly. What if there was a nice way to use a scoped lock? Kinda like in C#:

lock(lk_var) {
    var++;
}

Now, there certainly is an obvious solution in C++ -- some people call it a lock instance, others a critical section. All it does is create a class instance inside a scope. The class has a constructor and a destructor that grab and release the lock appropriately. Looks nice and clean:

{
    lock_instance l(lk_var);
    var++;
}

The only gotcha is, there is some overhead involved in this approach. The class instance takes up some space on the stack (several bytes) for every lock acquisition. Also, not completely sure on that, but the constructor and destructor calls might not get inlined. Now, in the real world this overhead is probably completely justified and noone would care about a few extra bytes of stack usage.

But, for science, last night me and some colleagues started wondering if there's a zero-overhead way of achieving the same effect. After a lot of discussion around crazy solutions with C++ lambdas or template metaprogramming, Bob Adolf (huge kudos!) came up with a surprisingly simple one that even works in C99. We can just use a one-iteration for loop, grab the lock on the initialization condition, and release it on the increment. After a few iterations on properly abusing C syntax, here's the final snippet:

#define LOCKED(lk) for(int i=0; (i < 1) && !lk_lock(lk); lk_unlock(lk), i++)

LOCKED(lk_var) {
    var++;
}

Let's walk through. On initialization, we set a loop counter. Then, on the first end condition test, we invoke lk_lock to grab the lock. Then, we execute the protected statements in the scope, and call lk_unlock in the loop increment to release the lock. The fun part is, at the second end condition test, the call to lk_lock gets short-circuited, we exit the loop and go on with our lives.

Thinking about correctness, the && short-circuiting is safe, because in C/C++ there is a sequence point associated with the && operator and we are guaranteed that (i < 1) will get executed first. Ideally, we'd want the lock call in the loop initialization statement, but we can't both declare the loop counter there and do a function call. So we do need the short-circuit trick.

But wait a second (one might say), you said you wanted zero overhead, but just introduced a loop counter, some checks on it, and an increment. How is that better than the lock instance solution? Well, any optimizing compiler worth its salt should figure out that this is a one-iteration loop, unroll it once and remove the unused induction variable. After some light testing, gcc 4.7.2 with -O3 definitely does, and the generated code is exactly the same as the verbose version we started with. Which was the purpose of the whole exercise.

What do you think? Any gaping holes that we missed? Did we just rediscover the wheel?

EDIT: As the nice folks on Hacker News pointed out, the instance-based solution will also get optimized away. On top of that, it is exception-safe, which the macro above isn't. So, don't do that, use a C++11 std::lock_guard instead.