4 ms·

First, implementation of efficient and reliable threaded code revolves around one simple and basic principle: follow your design. That implies, of course, that

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.

yread 15y ago
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).
- hythloday 15y ago
  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.
  - telent 15y ago
    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."
telent 15y ago
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)
- tptacek 15y ago
  Huh? attr_accessible is the whitelist feature; the argument was that it should have been non-optional.
  - telent 15y ago
    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
- hythloday 15y ago
  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?
- nknight 15y ago
  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.

yread 15y ago

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

hythloday 15y ago
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.
- telent 15y ago
  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."

telent 15y ago

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)

tptacek 15y ago
Huh? attr_accessible is the whitelist feature; the argument was that it should have been non-optional.
- telent 15y ago
  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
hythloday 15y ago
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?
nknight 15y ago
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.