4 ms·

I hate blog posts like this. You get one guy, who is seemingly very smart, and he says basically "Don't do multithreading, it's very hard. Only an elite few,

by steven2012 11y ago

I hate blog posts like this. You get one guy, who is seemingly very smart, and he says basically "Don't do multithreading, it's very hard. Only an elite few, such as me, can do this right, so most of you out there DON'T DO IT!" It's bullshit. Mainly because it's no harder than anything else, and has just as much pitfalls as every other type of programming. Yes, to a certain degree multithreading is hard, but it's not rocket science. But PROGRAMMING is hard. Not just multithreaded programming. There's nothing very special about multithreaded programming that should scare off people from trying it. Sure, you might fuck up, but that's For example, our entire company was almost completely brought down a few months ago by our "architect" implementing a feature so poorly that it caused massive system instability. What was this feature? It essentially boiled down to a 1 or a 2. Customer accounts were tagged with either a 1 or a 2, an it's supposed to take a different code path for each, but he made it so fucking complicated and he didn't do his due diligence, the entire weight of his code cause significant downtime, and a customer that accounts for 60% of our revenues almost walked. And none of this is rocket science. Of course, I worked at another company where one engineer thought "oh, asynchronous APIs are faster than synchronous APIs" so they implemented the entire API asynchronously. Of course, that required mutexes on the server side. And then more mutexes. And it got to the point where the performance was hell because of the unintended consequences of trying to make things faster. You would write a new API and the server would barf saying "You took the locks in the wrong order" but there was no indication of you ever doing anything wrong. It was a mess. So I get what the OP is saying, but it's not specific to just multithreadedness. I bet the same programmer would have made a mess of a single-threaded app as well. They are just shitty or careless programmers. If you're careful, multithreaded programming is helpful and you can see some significant performance boosts from it. But like every other paradigm in programming, don't overuse it. A judicious use of simple multithreaded programming might help a lot, but there are few apps that benefit from an extremely complex system with hundreds of threads, massive amounts of mutexes, etc.

hamburglar 11y ago
The reason I bristle about blog posts like this is that there are two wholly disparate types of multi-threaded programming: First, there's the type that's hard and should probably be avoided except by supergeniuses. This involves big hairy lock graphs where locks are held across complex operations that may involve other locks, and swirling dependencies of doom. This shit is nasty, and I completely agree that you must be "this tall" to be trusted with it. The other kind of multi-threaded programming is the simple kind, where you need to have a threadsafe interface to a module, the locking is dead simple if you know what you're doing, and your lock graph has about three states, all of which clear in constant time and have no dependencies. In this case, there is no excuse for not having this basic competency, and the attitude that we should all just throw up our hands and never hope to write multi-threaded code again is massively counterproductive. This shit is not brain-bendingly hard, it just takes a small amount of practice and discipline. Let's stop pretending all multi-threaded programming is wizardry.
- bholley 11y ago
  I think you're both misinterpreting the title. The sign is near the ceiling. It's not a question of some people being taller than others. Nobody is that tall - not even dbaron (pictured in the photo), who is one of Mozilla's three Distinguished Engineers. Carefully balancing swirling dependencies of doom doesn't make you a great programmer, at least not in the world of large-scale systems. Choosing the right design to avoid or eliminate those swirling dependencies is much more important.
  - hamburglar 11y ago
    That's fine, and I even agree -- perhaps nobody should venture into the swirling dependencies of doom territory with multi-threaded programming. However, my point is that this type of argument makes it seem as though nobody should attempt the more mundane, turn-the-crank, not-very-hard multi-threaded programming either, which is a bad attitude to perpetuate.
    - deleted 11y ago
      [deleted]
fauigerzigerk 11y ago
Multithreaded programming is not inherently more complicated than everything else, but finding bugs caused by multithreading is inherently more difficult than finding any other kind of bug. It all comes down to this: You can't reliably find concurrency bugs via testing. You have to prove they don't exist or you will never know. "Don't do it!" is one way of proving that multithreading bugs don't exist. But I find it annoying when people act like it is always down to choice. Sometimes we need shared mutable state for logical reasons. We can only avoid it where it is an implementation detail.

hamburglar 11y ago

The reason I bristle about blog posts like this is that there are two wholly disparate types of multi-threaded programming: First, there's the type that's hard and should probably be avoided except by supergeniuses. This involves big hairy lock graphs where locks are held across complex operations that may involve other locks, and swirling dependencies of doom. This shit is nasty, and I completely agree that you must be "this tall" to be trusted with it. The other kind of multi-threaded programming is the simple kind, where you need to have a threadsafe interface to a module, the locking is dead simple if you know what you're doing, and your lock graph has about three states, all of which clear in constant time and have no dependencies. In this case, there is no excuse for not having this basic competency, and the attitude that we should all just throw up our hands and never hope to write multi-threaded code again is massively counterproductive. This shit is not brain-bendingly hard, it just takes a small amount of practice and discipline. Let's stop pretending all multi-threaded programming is wizardry.

bholley 11y ago
I think you're both misinterpreting the title. The sign is near the ceiling. It's not a question of some people being taller than others. Nobody is that tall - not even dbaron (pictured in the photo), who is one of Mozilla's three Distinguished Engineers. Carefully balancing swirling dependencies of doom doesn't make you a great programmer, at least not in the world of large-scale systems. Choosing the right design to avoid or eliminate those swirling dependencies is much more important.
- hamburglar 11y ago
  That's fine, and I even agree -- perhaps nobody should venture into the swirling dependencies of doom territory with multi-threaded programming. However, my point is that this type of argument makes it seem as though nobody should attempt the more mundane, turn-the-crank, not-very-hard multi-threaded programming either, which is a bad attitude to perpetuate.
  - deleted 11y ago
    [deleted]

fauigerzigerk 11y ago

Multithreaded programming is not inherently more complicated than everything else, but finding bugs caused by multithreading is inherently more difficult than finding any other kind of bug. It all comes down to this: You can't reliably find concurrency bugs via testing. You have to prove they don't exist or you will never know. "Don't do it!" is one way of proving that multithreading bugs don't exist. But I find it annoying when people act like it is always down to choice. Sometimes we need shared mutable state for logical reasons. We can only avoid it where it is an implementation detail.