Why does Posix have recursive mutexes? Because of a dare. | Hacker News Reader

Why does Posix have recursive mutexes? Because of a dare.

groups.google.com

111 pointssigna1114 comments

First, implementation of efficient and reliable threaded code revolves around one simple and basic principle: follow your design. That implies, of course, that you have a design, and that you understand it. A correct and well understood design does not require recursive mutexes

This is quite a startling position for a library author: don't supply convenient constructs that could be misused if they aren't absolutely necessary. Without any desire to be snarky about the hard work that went into POSIX, I'm glad as a discipline we've move on in the last 20 years.

I don't agree. As a library designer you have to DESIGN in the first place. It pays off to think through the use cases of the users of your library. Allowing every possible way of doing things and seeing what sticks makes your library more complicated. You have to test and document all these alternatives. People will inevitably sometimes choose the wrong way of doing things, end up with underperforming or buggy code and blame you.

Especially in synchronization it pays off to go with the simplest solution. Unless you know very well what you're doing (and wrote some formal verification that it can't break under any circumstances).

I pretty obviously didn't mean that the library designers should just throw out a bunch of stuff to see what gets used. Re-entrant locks seem to fall into the same design space that memory checking in debug C runtimes does: you never want to need to use it but if you do need to use it you want it to be there. Designing for the perfect case is poor design, imho, because we live in an imperfect world.

The difference is that memory checking in debug C runtimes doesn't paper over your mistake: instead it breaks your program reliably so that you know you have a mistake. As per the linked article, "While recursive mutexes may seem a convenience for debugging, in fact it's the opposite -- you're better off with a "strict" debugging mutex (like the POSIX error-check attribute) that checks, tracks, and enforces ownership restrictions a "normal" mutex may ignore in favor of runtime efficiency."

Compare and contrast with the Rails attr_accessible kerfuffle of last week, where it was generally held by (I think) the majority of commenters that the library should not have provided this convenient feature or at least should have made it more difficult to enable.

I'm right there with this "startling" (some would say "opinionated") position. And so is my C library, which complains at me every time I compile a program using getwd()

("my" as in the one I have installed here. I am making no ownership claim)

Huh? attr_accessible is the whitelist feature; the argument was that it should have been non-optional.

Indeed it is as you say. "attr_accessible kerfuffle" was my (apparently, and quite bizarrely, considered inflammatory) shorthand to refer to the whole episode. I'd edit the post to clarify, but it won't let me do that any more

Heh, I'm certainly not against static analysis and warnings. The library author is talking about not making locks re-entrant, though, which would mean that in the case where you accidentally try to use a lock that way, the program either crashes or deadlocks. That's the better solution?

Yes. Contrast. Massive contrast.

The Rails "kerfuffle" was about unnecessarily dangerous default settings affecting a widely-used (including in official tutorials) mechanism.

To even get a recursive mutex in POSIX, you have to explicitly ask for one, they're not even mentioned in most (any?) tutorials, they don't pose any direct security threat, and unlike Rails, POSIX threads are not a common thing for brand-new developers to be using, much less in anything exposed to the public Internet.

I think you've jumped at a different parallel than the one I was trying to draw. It's considered a bad thing that Rails prioritised developer convenience over the encouragement of reliable programming practice. Why should it be considered a good thing for a Posix standard to take the same position? Ignore questions of reach and impact, the comparison is one of attitude not of effect.

Irrespective of what the tutorials say, many developers will go reaching for a recursive lock the first time they get a recursive deadlock - especially if they come from a Java background - and tutorials or no, it's not as though the information is hard to find. Five minutes browsing Stack Overflow will quickly disabuse you of any perception that all the people writing POSIX threaded apps are in any way particularly gifted, even compared to Rails developers

No, it's considered a bad thing that Rails had insecure defaults in a recommended code path used by legions of inexperienced developers. You can still change the setting to the old value if you want to, just like you can explicitly ask for a recursive mutex if you want one. Bonus: Asking for a recursive mutex still isn't a security problem.

And since you want to argue based on SO, I'll just leave you with two bits of data from SO:

http://stackoverflow.com/questions/tagged/pthreads -- 1,525 questions

http://stackoverflow.com/questions/tagged/ruby-on-rails -- 66,675 questions

Guess what? I consider that a bad thing too.

But you're still reading things into my comment other than what I said.

(1) Rails had insecure defaults which encourage bad programming

(2) pthreads has an API which - at least, in its designer's view - fails to sufficiently discourage bad programming.

(3) The post I was originally responding to was suggesting that it would be in some way an unusual mindset ("startling" was the actual word used, I think) for a library author to wish to discourage bad uses of his library. I think otherwise. Rails was pretty much the first (recent, well-known) example that came to mind where a library author had (imo, anyway) not sufficiently discouraged bad uses of his library.

That's all. I make no argument about the comparative size of the communities,nor the comparative intellectual smarts of their members, nor the reach/impact of the design decisions that the library authors made in each case. That's all I said. Library authors can and do and should design their libraries to encourage their consumers to do the right thing, and this should not be startling.

Dear HNers: please stop linking to pages that require visitors to log-in.

Dear Google: please stop requiring authentication to read public google group messages.

I'm reading it and I'm not logged in. I think I remember this is a bug in google groups, it will ask you to log in if you have an old google cookie, it used to happen to me too a year ago, try to delete your google cookies.

Reply on news.ycombinator.com