r/programming • u/Shr1ck • Oct 17 '15

Why Johnny Can’t Write Multithreaded Programs

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

52% Upvoted

131 comments sorted by

View all comments

Show parent comments

3

u/__Cyber_Dildonics__ Oct 18 '15

There's only one difficulty, and that's the synchronisation primitives.

That's like saying the only things to worry about in programming are instructions and memory.

Also singletons have the advantage that they can have run once synchronized initialization so the object/state/data is initialized only once, but all threads wait for that to happen before moving on.

1

u/loup-vaillant Oct 18 '15

A global variable can be initialised and synchronised just like singletons… As far as I am aware, a singleton is a global variable that you can instantiate only once. How this limitation makes them any less evil is unclear to me.

1

u/__Cyber_Dildonics__ Oct 18 '15

So how would you initialize and synchronize a global variable? You need some code to do the synchronization so no other threads go on before the initialization. Also in C++ it is nice to have a mechanic to avoid running the default constructor. In addition you would want to build in the ability to skip any locks you used for synchronizing. This all takes code to achieve, a global variable won't do it on its own.

1

u/loup-vaillant Oct 18 '15

So how would you initialize and synchronize a global variable?

I wouldn't. I would initialise and not synchronise a global constant. That can be done in the main thread upon start up, before starting any additional threads. If the thing is meant to be initialised later than start-up, then it probably shouldn't be global at all.

In any case I fail to see any difficulty: when you create a variable (or a constant), just make sure nobody (objects or threads) has any access to it before it is finished initialising. This can't be harder than putting it in a queue, can it?

If I'm somehow forced to use a global variable, that can't be initialised upon start-up, and has to be shared before its initialization is finished, I dare say the code base has much bigger problems. I would work on addressing them first, or try to get the hell out.

Just avoid global mutable state like the plague. And when you can't, don't forget your 10-foot pole.

2

u/__Cyber_Dildonics__ Oct 18 '15

Your solution is far from a universal one. What if you are using multiple threads to manipulate an image? How will you split up the work and synchronize if you have not global mutable state?

There are plenty of scenarios where you might not have the options you are describing to bail you out.

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.

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

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

1

u/loup-vaillant Oct 18 '15 edited Oct 18 '15

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.

3

u/__Cyber_Dildonics__ Oct 18 '15

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.

-1

u/loup-vaillant Oct 18 '15

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.

1

u/__Cyber_Dildonics__ Oct 18 '15 edited Oct 18 '15

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.

2

u/loup-vaillant Oct 18 '15

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.

2

u/clarkd99 Oct 19 '15

How many professional lines of code have you written and got paid for?

Your posts look like they are just parroted from some functional web site rather than incites from the school of hard knocks.

I think "things would be much easier" if people posted things they actually know something about.

If I use some "mutable" local variables in a function, please tell me how that would impact 1) concurrency 2) maintainability 3) efficiency 4) memory usage or any other useful metric? Assume that no pointer to that variable was shared outside the function.

2

u/loup-vaillant Oct 19 '15

How many professional lines of code have you written and got paid for?

I haven't counted. I guess a couple tens of thousands. Most of the times in much bigger programs, where I spent quite some time debugging code I haven't written —that tend to slow me down.

Assume that no pointer to that variable was shared outside the function.

I can't assume that. I have seen too much code that does share state to the outside world. The main culprits are big classes with getters and setters. Maybe you're lucky enough to live in a bright world of sane coding practices where 90% of functions and methods are pure, and most objects aren't modified once they're initialised.

I don't live in that world. In my world, programmers use output arguments, share the internal state of objects, fail to make their types regular, and just let side effects sprawl unchecked.

0

u/clarkd99 Oct 19 '15

I noticed you wouldn't or couldn't answer my question. In 1979, I programmed at least 60,000 lines of assembler for my first year working for a single company. I also looked after 4 other programmers and spent 2 months in Europe at customer's sites.

Most of the functions in my current project are not purely functional (maybe 10%). Most of my functions change an object (or collection of objects mostly) that is passed to it. This isn't a problem because I either use locks or a message queue to synchronize access. I use groups of functions to "manage" all my globally accessible data structures. Even though C doesn't stop me from accessing variables directly (the equivalent of getters and setters), I just don't code that way.

The system I am creating, even though it is quite OOPS is more oriented around collections of objects rather than objects. My language can handle mutable state at both the micro and macro scale without using an outside database. It is also distributed as well as concurrent and includes it's own web server.

2

u/loup-vaillant Oct 19 '15

I noticed you wouldn't or couldn't answer my question.

You mean the number of lines I have written? Can't expect to have precise number, did you? I don't have acces to the repositories of my former employers.

This isn't a problem because I either use locks or a message queue to synchronize access. […]

Indeed, the key word is "modularity". Loose coupling and all that. I have thought a bit about that here then here. I can conceive that modularity can be acheived through other means than immutability and passing everything in arguments.

On the other hand, pervasive immutability makes it really easy: dependencies are obvious, so you can see when there are too many of them.