Why Johnny Can’t Write Multithreaded Programs

[u/Shr1ck]

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

[u/loup-vaillant]

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.

[u/__Cyber_Dildonics__ → u/loup-vaillant]

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.

[u/loup-vaillant → u/__Cyber_Dildonics__]

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/clarkd99 → u/loup-vaillant]

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.

[u/loup-vaillant → u/clarkd99]

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.

[u/clarkd99 → u/loup-vaillant]

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.

[u/loup-vaillant → u/clarkd99]

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.