The real advantage of a scoped lock is that it promises to release the mutex, no matter how the scope is exited. If this LOCKED macro is used and an exception is thrown from within the block, that mutex now stays locked.<p>> 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.<p>Not so fast. A decent compiler will eliminate the overhead and not actually allocate stack space for the lock. Here's an example using one of the lock guards in C++:<p><pre><code> struct foo {
int var;
std::mutex m;
};
void process1(foo& f) {
std::lock_guard<std::mutex> lock(f.m);
++f.var;
}
void process2(foo& f) {
f.m.lock();
++f.var;
f.m.unlock();
}
</code></pre>
GCC 4.8.1 generates identical code for process1 and process2.
I fail to see the point of using a macro (ew) to accomplish something that's included, with several different implementations, in the c++11 standard library
Don't do this. The whole thing gave off a bad smell on first reading so I would never have done this.<p>Thank you vinkelhake for nailing the the real problem (exceptions) and bothering to check whether the stack overhead really exists.<p>Just wanted to chime in with a comment because HN doesn't show vote counts, so future readers will "see" my upvote on vinkelhake's comment.
Exception issues aside, an odd definition of "scoped". A very non-C++ solution. Use RAII and lock_guard (if possible) as vinkelhake demonstrates. Consider,<p><pre><code> LOCKED(lk_var) {
return 42; // whoops
}</code></pre>
You're also consuming the variable name i, which everyone else is probably using.<p>Speaking of which, this means you can't have one of your locks scoped inside another one.
This kind of thing is one area I'm excited to see work in Rust: you can use Rust's safety guarantees to ensure that all access goes through the lock.
What about:<p><pre><code> #define LOCKED(lk) for(int i=lk_lock(lk); i == 0; lk_unlock(lk), i++)
</code></pre>
Probably better to test for 0 exactly, in case it fails. You don't want it to unlock twice just because it returns -1.
A very important gotcha with this approach is that any variable named "i" will be reset to 0 inside of the lock, and modifying "i" inside of the lock can cause an infinite loop.<p>This can be mitigated by generating a unique variable name with the C preprocessor: <a href="http://stackoverflow.com/questions/1132751/how-can-i-generate-unique-values-in-the-c-preprocessor" rel="nofollow">http://stackoverflow.com/questions/1132751/how-can-i-generat...</a><p>That being said, it's much better to use a standard method of scoped locking instead of trying to reinvent the wheel.
I learned about the for loop hack from avr-libc[1][2]. It even does some preprocessor abuse to implement different kinds of atomic and non-atomic sections.<p>[1] <a href="http://www.nongnu.org/avr-libc/user-manual/group__util__atomic.html" rel="nofollow">http://www.nongnu.org/avr-libc/user-manual/group__util__atom...</a><p>[2] <a href="http://svn.savannah.nongnu.org/viewvc/trunk/avr-libc/include/util/atomic.h?root=avr-libc&view=markup" rel="nofollow">http://svn.savannah.nongnu.org/viewvc/trunk/avr-libc/include...</a>
Wouldn't this be exception-safe, provided lock_iter defines a ctor, dtor, operator bool() and operator ++()?<p><pre><code> #define LOCKED(lk) for (lock_iter i = lk; i; i++)
</code></pre>
(Edit: I thought lock_iter could be an empty class but no, it can not, so I edited my post. lock_iter will have an internal flag that should be optimized away following the same logic int i is optimized in the OP's version)
People have already pointed out the specific problems with this approach so I won't repeat them.<p>It's worth reiterating, though: If you are writing c++ these days and find yourself reaching for a preprocessor macro, I think that's a good sign you should think really carefully about what you are actually trying to do. Chances are really good there is a (much) better way.
Boost.Scopexit addresses this point pretty well I think: <a href="http://www.boost.org/doc/libs/1_55_0/libs/scope_exit/doc/html/index.html" rel="nofollow">http://www.boost.org/doc/libs/1_55_0/libs/scope_exit/doc/htm...</a>
folly::Synchronized implements this in a correct way (and also prevents access without acquiring the lock):<p>SYNCHRONIZED(data) {
// modify data
}<p><a href="https://github.com/facebook/folly/blob/master/folly/Synchronized.h" rel="nofollow">https://github.com/facebook/folly/blob/master/folly/Synchron...</a>