“When all you have is a hammer”: #CowboyDeveloper Edition

“Locking is easy — just use a mutex!”
        --#CowboyDeveloper

One of the surest “tells” of a #CowboyDeveloper is their behavior around a shared resources. Odds are they’ll slap a mutex around it (or around something), and keep going. Oh, if you really poke at them, they might be able to (intelligently? maybe not) say something about mutexes vs semaphores vs spin-locks vs …, but, seriously, in their mind, “It’s all so simple! You just lock/unlock it! Like, with mutexes!”

The above, mind you, as contrasted with the excellent work by Willy Tarreau (most definitely not a #CowboyDeveloper) on Progressive Locks.
“What are they?” you ask?
Well, if you’ve got a resource (tree, list, whatever) where you’re usually reading the resource, but, sometimes, you want to write only if your Read succeeded. In short, you want to be able to “upgrade” from a Read to a Write.
So, you come up with a new lock structure that supports the following 5 states:

• U (unlocked) : nobody claims the lock
• R (read-locked) : some users are reading the shared resource
• S (seek-locked) : reading is still OK but nobody else may seek nor write
• W (write-locked) : exclusive access for writing
• A (atomic-locked) : some users are performing safe atomic operations which are potentially not compatible with the ones covered by R/S/W.

The key is in the Seek state above, which doesn’t exclude readers, but, cannot be taken if another S or W lock is already held. But once the S lock is held, the owner is automatically granted the right to upgrade it to W without checking for other writers.

The point here isn’t the awesome coolness of Progressive Locks (•), it is actually to point out that Willy did a very specific thing here. He had a problem to solve (using ebtree in a thread-safe manner), and he didn’t just “put a mutex on it”. He
 — looked at the specifics of the problems,
 — figured out the locking behavior that was necessary,
 — realized that he actually needed something slightly different than what was available on the shelf
 — decided that the work was worth the reward
 — did the work,
 — tested it, benchmarked it, and documented it (and yeah, if you’re a #CowboyDeveloper, you’d never actually do this step, would you?)

There’s a lesson here, not just about locks, but about understanding problem domains and identifying solutions appropriate to these domains. About Engineering if you will. And it’s a lesson that, I fear, all too few people in our industry actually take to heart…

(•) Progressive Locks are cool though. And ridiculously performant. Much more information on them here, and code here.