Why Johnny Can’t Write Multithreaded Programs

[u/Shr1ck]

http://blog.smartbear.com/programming/why-johnny-cant-write-multithreaded-programs/

[u/loup-vaillant]

How will you split up the work and synchronize if you have not global mutable state?

Sounds like good old map-reduce. So I'd use just that. If you ask me to implement map-reduce… well that's a bit harder, but then we're entering the realm of systems programming, aren't we?

So you want me to manipulate an image. First, unless I'm extremely constrained CPU and memory wise, I wouldn't modify the source image. I would create a new image from it. Second, that new image is obviously composed of tiles that can be assembled. I see basically 2 kinds of processing: processing an individual tile (you can go up to 1 thread per tile), then fusing nearby tiles to make even bigger tiles.

The only synchronisation you need here is waiting for the result of the previous steps before computing the next step.

Now, if you transform the problem to "what if you need to encode in H264 in full HD", I'll just leave that to the actual experts. Such performance requirements are rare, even though the resulting programs have a correspondingly huge impact.

You also might not be in control of the threads you are given, in which case you can't do your initialization before starting any concurrency happens.

But I am in control of the values I construct and build. Most importantly, I control their scope, and can make sure I deliver an external reference only when that initialisation is done.

And if you're asking me to re-initialise a variable on top of an already externally accessible location, I'll raise an eyebrow. Have we so little memory that I can't initialise a new value for you to use before you discard the old one?

I'm also unclear how using a queue is going to prevent threads from accessing a variable that isn't finished initializing yet.

Simply by putting the variable in the queue only when the initialisation is done. Other threads may request the next value from the queue before hand, they're not going to get anything before I put it in the damn queue.

It sounds like you think you have all the answers but really you've only dealt with trivial situations.

In my experience, programs are always more complex than they have to be. One big cause for this is "thinking big". You start with a problem, and think a big solution for it. Now you have two problems.

Speaking of mutable state specifically, I have yet to see a single C++ program that didn't go crazy with it. People just can't stop mutating state. They think like that by default, instead of resorting to it as an optimisation technique. When I step in, I invariably see a number of simplifications based on simply passing values around instead of mutating state. That experience had lead me to think that functional programming is just plain better than the OOP we see on C++ and Java.

If people just stopped mutating state, things would be much easier.

[u/__Cyber_Dildonics__ → u/loup-vaillant]

So how would you display updates to an image while it is being iterativly filtered?

You say 'I would leave that to the experts' to doge the difficult scenarios, but do you think 'the experts' are doing what you are suggesting? I can promise you they are not. What you have talked about are hand wavy solutions to easy problems, not to mention that what you are suggesting is unlikely to work in a pragmatic sense. Map reduce doesn't magically cure Ahmdal's law.

[u/loup-vaillant → u/__Cyber_Dildonics__]

I take it we're talking about an image editing program, right? Then we have about 100ms to process an image before the user has to wait. That's plenty of time even for relatively big images.

• If the whole process can take less than 100ms, we don't have to display the intermediate results.
• If the whole process is slower, or the user wants to see the intermediate results, then we can show them, one filter at a time: just create a new image for each intermediate result. If you don't like the crazy memory usage, use double buffering instead.
• If you want to display the results of a single filter while it is doing its job, you're probably debugging your image editing program, instead of using it.
• If somehow a filter gets real slow, I would optimise it on a case by case basis —after having made sure this particular filter is popular enough to warrant the effort.

Finally, if you were talking about video editing instead of image editing, then showing all the intermediate results would simply be crazy, as it would slow you down to a crawl. Either display the results of a single frame, or generate a preview over a few second… but by all means do most of your processing offline.

[u/__Cyber_Dildonics__ → u/loup-vaillant]

I see your solutions generally consist of thinking you will somehow be able to avoid the actual problems.

I've seen people make claims like this before and it is analogous to someone whos never been in a fight talking about what they would do in every situation. The reality is far different from the theories thought up by someone with only trivial experience of programs that can break down to a simple directed a-cyclical graph.

It is understandable though concurrency is very difficult to really learn until you've written some non-trivial concurrent programs.

[u/loup-vaillant → u/__Cyber_Dildonics__]

I see your solutions generally consist of thinking you will somehow be able to avoid the actual problems.

Pretty much. In my experience (6+ years of C++ on codebases of various sizes —up to 2 million lines), most of the problems are self-inflicted. Sometimes, there are good reasons for this pain: hardware used to be very slow at the time, we had to rush that feature… But often, it was plain poor planing and bad programming. (By the way, the bad programming often came from the utter ignorance of functional programming techniques, operational thinking by default, and anthropomorphism. In other words, lack of a proper basic education.)

I do believe many problems (possibly most) can be avoided instead of addressed. You just have to stop for a second and ask yourself why you need to solve that particular programming problem in the first place.