Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

In the C++ bag of tricks: scoped locks

blog.skanev.org

Post reply on HN
Print view View original

21–30 of 56 posts

Re: In the C++ bag of tricks: scoped locks

#21

Post by lbrandy »

vinkelhake wrote: post #5

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. > 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…

Indeed. Sorry OP, your solution:

(1) avoids best practice (RAII) using...

(2) a flawed rationale (ignoring the existence of compiler optimizations)...

(3) without measurement to demonstrate the supposed flaw in the best practice (which would have surfaced the flawed rationale)...

(4) and therefore implements a micro-optimization with no actual win...

(5) and introduces a bug in the process (it's not exception safe).

Re: In the C++ bag of tricks: scoped locks

#25

Post by 8_hours_ago »

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.

This can be mitigated by generating a unique variable name with the C preprocessor: http://stackoverflow.com/questions/1132751/how-can-i-generat...

That being said, it's much better to use a standard method of scoped locking instead of trying to reinvent the wheel.

Re: In the C++ bag of tricks: scoped locks

#26

Post by s_kanev »

lbrandy wrote: post #21
vinkelhake wrote: post #5

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. > 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…

Indeed. Sorry OP, your solution: (1) avoids best practice (RAII) using... (2) a flawed rationale (ignoring the existence of compiler optimizations)... (3) without measurement to demonstrate the supposed flaw in the best practice (which would have surfaced the flawed rationale)... (4) and therefore implements a micro-optimization with no actual win... (5) and introduces a bug in the process (it's not exception safe).

OP here. Totally agree. TIL about RAII. That particular codebase doesn't use c++ exceptions, but still not a reason for a roll-your-own solution if something as efficient is in the standard library.

Re: In the C++ bag of tricks: scoped locks

#27

Post by dicroce »

s_kanev wrote: post #26
lbrandy wrote: post #21

Earlier quoted context omitted.

Indeed. Sorry OP, your solution: (1) avoids best practice (RAII) using... (2) a flawed rationale (ignoring the existence of compiler optimizations)... (3) without measurement to demonstrate the supposed flaw in the best practice (which would have surfaced the flawed rationale)... (4) and therefore implements a micro-optimization with no actual win... (5) and introduces a bug in the process (it's not exception safe).

OP here. Totally agree. TIL about RAII. That particular codebase doesn't use c++ exceptions, but still not a reason for a roll-your-own solution if something as efficient is in the standard library.

Does it use the STL? The STL will throw. Does it use the new operator? new will throw unless you specifically tell it not to.

Re: In the C++ bag of tricks: scoped locks

#29

Post by s_kanev »

dicroce wrote: post #27
s_kanev wrote: post #26

Earlier quoted context omitted.

OP here. Totally agree. TIL about RAII. That particular codebase doesn't use c++ exceptions, but still not a reason for a roll-your-own solution if something as efficient is in the standard library.

Does it use the STL? The STL will throw. Does it use the new operator? new will throw unless you specifically tell it not to.

Ok, should've been more specific -- it doesn't catch any exceptions and lets them bring down the program and have the project maintainer check what they did wrong.
Post reply on HN