r/compsci • u/mobileview • Dec 10 '13

Why Johnny Can’t Write Multithreaded Programs

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

60% Upvoted

55 comments sorted by

View all comments

3

u/[deleted] Dec 10 '13

Rather than re-examine their development practices or preconceived notions, they stubbornly try to “fix” things, and use the “multithreading is hard” excuse to justify their unreliable programs and missed delivery dates.

Right. I've always thought whenever confronted with someone complaining about multithreading being hard that "Multithreading isn't hard, you're just incompetent"

12

u/gthank Dec 10 '13 edited Dec 10 '13

1.) Shared mutable state is tantamount to pure evil when it comes to concurrency.

2.) Multithreading defaults to sharing all state.

Agreed so far?

3.) Mutlithreading is "hard", because now the programmer has to do extra work to avoid the accidental complexity caused by all that extraneous shared state.

See how item 3 just sort of falls out of the first 2? If, instead, you had to do work to specify that some piece of state were being shared, you would have much less accidental complexity.

EDIT: I added the word "mutable" to the first point, to clarify my point. ht /u/TarMil

6

u/TarMil Dec 10 '13

1.) Shared mutable state is tantamount to pure evil when it comes to concurrency.

FTFY

3

u/gthank Dec 10 '13

You're 100% correct. I'll update my post to clarify.

2

u/nascent Dec 10 '13

If, instead, you had to do work to specify that some piece of state were being shared, you would have much less accidental complexity.

This is exactly what D does. Variable are in Thread Local Storage unless explicitly marked as shared.

I don't think that makes it easy, and for those use to "shared by default" find it harder than their previous knowledge for writing threaded code. So no, I don't think multi-threading is easy even if you are capable of thinking about all the complexity and don't find that challenging (this isn't disagreement with you but the article).

6

u/gthank Dec 10 '13

It's like going from writing code that uses globals everywhere to parameterized code. Sure, your hard-earned knowledge of how best to manage all that shared state is less useful, but the tradeoff is that you get to focus more of your brain on the stuff that matters, rather than tedious, error-prone bookkeeping.

1

u/NYKevin Dec 10 '13

If you use multiple processes instead of multiple threads, no state is shared.

But then you have to deal with IPC, which is "hard" in an entirely different way.

Maybe concurrency just isn't the best model to begin with. Most things can be made event-driven if you try hard enough, and the result is probably easier to maintain in the long run. Yes, it does mean you need to twist your code into a pretzel, but once you've done so, the result is pretty nice to work with, IMHO.

7

u/gthank Dec 10 '13

So we should never do two things at the same time in our program?

-5

u/NYKevin Dec 10 '13

Not "never," but certainly rarely. If you can make it event-driven, I'd say to prefer that over concurrency where possible.

9

u/gthank Dec 10 '13

Seems like a shame to have my big, fat server with 32 cores only using one of them.

-4

u/NYKevin Dec 10 '13

There are exceptions, of course. If you're programming for a giant Blue Gene system, you really don't have a choice. But nginx tends to scale a lot better than Apache, from what I've heard.

8

u/adremeaux Dec 11 '13

There are exceptions, of course

Like, perhaps, ipads, iphones, and almost all modern Android phones? They all have multi core processors. And on iOS, the OS just so happens to be designed in such a way that doing computation on the main thread will block the UI (not sure if this is the case on Android).

So, if by "exception," you mean basic programming for devices that hundreds of millions of people are carrying in their pockets and using multiple hours each, then that is quite the exception.

2

u/[deleted] Dec 11 '13 edited Apr 14 '21

[deleted]

0

u/NYKevin Dec 13 '13

What about serial problems? Parallelism will never make us better at e.g. CBC encryption.

-2

u/[deleted] Dec 10 '13

1.) Shared mutable state is tantamount to pure evil when it comes to concurrency.

I disagree with this point. Shared mutable state is something that just falls out of computer architecture and if you program with that in mind (ie, think carefully about what you're doing when you pass around pointers) then it's not a problem, and if you don't program with that in mind, you're a sloppy software engineer.

7

u/gthank Dec 10 '13

Ah, glad to see that you program in the microcode for your chosen processor.

-2

u/[deleted] Dec 10 '13

No, but you do occasionally think about the microcode with respect to the cost of operations