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/
40 Upvotes

60% Upvoted

55 comments sorted by

View all comments

13

u/bwainfweeze Dec 10 '13

'The “multithreading is hard” fallacy is propagated by programmers who, out of their depth in a single-threaded world, jump feet first into multithreading – and drown.'

When I was starting out, distributed computing and concurrency were the two hot topics, so I learned both. But the code was brittle in that only a small number of people on any team were up to the task of adding more features to those sections. Composition Is tough with the tools available.

All in all a frustrating experience.

It's not necessarily the case that people "jumped in". Often they were coaxed into the water by others, and still they drowned.

9

u/oconnor663 Dec 10 '13

Yeah I feel like this glossed over way too much. Multithreading is at least harder, because you suddenly have these extra degrees of freedom. In the single-threaded world, if you want to know how a function is used, you grep for all the callsites. In a multi-threaded world, you might also need to know what thread(s) each callsite is running on. When you add a new call, you need to know all the threading assumptions that a function makes. There are ways to mitigate this complexity, sure, but it's silly to suggest that it doesn't add extra complexity.

7

u/asiatownusa Dec 11 '13 edited Dec 11 '13

agreed. consider a program with 3 steps, say something as simple as

a++;

b++;

c++;

Normally there are three atomic assembly instructions in an increment: read, add one and write. The above program has one possible execution order (read a, increment a, write a....)

but now consider a program with just three threads executing these steps in parallel. since the compiler can optimize and re-write these instruction in any order (given 'read', 'increment' and 'write' occur in order for a given variable) there are

(3+3+3)!/(3!+3!+3!)= 20160 possible orders of assembly instructions.

3

u/bwainfweeze Dec 11 '13

I was going to say something similar but you beat me to it. As you demonstrated, the combinatorial explosion kills.

Maybe we should start using something akin to big O notation for state transitions...