In the C++ bag of tricks: scoped locks
blog.skanev.org
In the C++ bag of tricks: scoped locks
1–10 of 56 posts
Re: In the C++ bag of tricks: scoped locks
#2What about:
#define LOCKED(lk) for(int i=lk_lock(lk); i == 0; lk_unlock(lk), i++)
Re: In the C++ bag of tricks: scoped locks
#3Works, but requires {} for scope. The local-object version can be scoped however you like. It optimizes away just fine, similar to the for loop.
Re: In the C++ bag of tricks: scoped locks
#4C++11 has scoped locks built-in, doesn't it?
Re: In the C++ bag of tricks: scoped locks
#5The 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.
> 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.
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++:
struct foo {
int var;
std::mutex m;
};
void process1(foo& f) {
std::lock_guard lock(f.m);
++f.var;
}
void process2(foo& f) {
f.m.lock();
++f.var;
f.m.unlock();
}
Re: In the C++ bag of tricks: scoped locks
#6The 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. > 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. Not so fast. A decent compiler…
This. For at least three typical 'best practice' reasons. I know there are times best practices can be nicely ignored, but this is not one of those occasions. On the contrary. Let me lay them out again:
- these are the days of C++11 where scoped locks are readily available
- premature optimization
- macros are evil
Re: In the C++ bag of tricks: scoped locks
#7The 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. > 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. Not so fast. A decent compiler…
Wait... if it's identical, how can it be safe against exceptions? `process2` isn't.
Re: In the C++ bag of tricks: scoped locks
#8You can do some of this with the cleanup attribute in GCC, although it doesn't trigger in the case of a longjmp.
Re: In the C++ bag of tricks: scoped locks
#9The 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. > 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. Not so fast. A decent compiler…
This. For at least three typical 'best practice' reasons. I know there are times best practices can be nicely ignored, but this is not one of those occasions. On the contrary. Let me lay them out again: - these are the days of C++11 where scoped locks are readily available - premature optimization - macros are evil
One of the reasons C++ gets bad reputation, is those Cisms that people insist on writing, when the language offers much better alternatives.
Re: In the C++ bag of tricks: scoped locks
#10The 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. > 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. Not so fast. A decent compiler…
Wait... if it's identical, how can it be safe against exceptions? `process2` isn't.
gcc can statically determine that incrementing f.var will not throw.