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

11–20 of 56 posts

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

#11

Post by stinos »

pjmlp wrote: post #9
stinos wrote: post #6

Earlier quoted context omitted.

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.

Which is mostly due to lack of education. If you don't ever spent time learning, but just coding, you don't know better. And sometimes it's all too easy to get thrapped into it due to deadlines and whatnot. A former collegue of mine, unfortunately, was the best example: programmed for like 15 years years and still wrote like it was all 'C with classes' (not that there ever was such a thing). You know, writing declarations at the top of functions etc. Missing out on C++11 is just as bad.

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

#12

Post by twoodfin »

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…

Yeah, they even admit that their macro compiles to identical code as the original RAII version. Where's the "overhead"?

As a general rule, if your C++ compiler can statically see the layout of your structures and the implementation of your functions, it will produce code as efficient as inlining everything yourself. Sufficiently complex functions make the benefits of inlining a judgment call on the compiler's part, but for something as simple as an RAII scoped lock, the abstraction is free.

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

#15

Post by khc »

dllthomas wrote: post #8

You can do some of this with the cleanup attribute in GCC, although it doesn't trigger in the case of a longjmp.

if you can rely on gcc, cleanup attribute is probably the best you can do. The solution in original post doesn't cope with "break", "continue", "return" (and of course, "goto", but I don't remember if cleanup attribute handles that either).

Looks like their project already uses C++ though, so why don't they just use C++ for this is beyond me.

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

#16

Post by dllthomas »

khc wrote: post #15
dllthomas wrote: post #8

You can do some of this with the cleanup attribute in GCC, although it doesn't trigger in the case of a longjmp.

if you can rely on gcc, cleanup attribute is probably the best you can do. The solution in original post doesn't cope with "break", "continue", "return" (and of course, "goto", but I don't remember if cleanup attribute handles that either). Looks like their project already uses C++ though, so why don't they just use C++ for this is beyond me.

Agreed.

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

#18

Post by [deleted] »

khc wrote: post #15
dllthomas wrote: post #8

You can do some of this with the cleanup attribute in GCC, although it doesn't trigger in the case of a longjmp.

if you can rely on gcc, cleanup attribute is probably the best you can do. The solution in original post doesn't cope with "break", "continue", "return" (and of course, "goto", but I don't remember if cleanup attribute handles that either). Looks like their project already uses C++ though, so why don't they just use C++ for this is beyond me.

[deleted]

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

#19

Post by taway2012 »

Don't do this. The whole thing gave off a bad smell on first reading so I would never have done this.

Thank you vinkelhake for nailing the the real problem (exceptions) and bothering to check whether the stack overhead really exists.

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.

Post reply on HN