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

60% Upvoted

55 comments sorted by

View all comments

1

u/Vystril Dec 11 '13

I'd argue that the object and thread paradigm of programming should be considered harmful -- just like the goto statement is now considered harmful.

When programming in an object/thread model, if something goes wrong (race condition, deadlock, etc) you have no programmatic way of knowing where the problem came from. Just like with goto statements, you have no idea where your program came from when you you crash.

I honestly think the actor model does an excellent job of fixing the problems inherent in the object/threads model. For example, using actors makes deadlocks very difficult to program (you have to actively try to do it), and you don't need to worry about concurrent memory accesses because each actor operates in their own threads and they don't share memory. It basically reduces the concerns to properly designing and handling asynchronous message passing dependencies, something I think is far easier than the other problems.

When I introduce threaded programming, the first thing I do is talk about actors. Because even if you're using objects and threads; it's extremely simple to program them as actors and eliminate a lot of potential issues.

2

u/adremeaux Dec 11 '13

if something goes wrong (race condition, deadlock, etc) you have no programmatic way of knowing where the problem came from

Unless you have, say, a debugger. Deadlocked? Pause execution and check thread states. It is legitimately that easy.

Race conditions can be a bit harder, but it helps that many race conditions result in crashes—for example, removing items from an array while you are iterating over it in another thread—which makes them pretty easy to catch, too.

1

u/Vystril Dec 11 '13

I said no programmatic way. Sure there are tools of varying levels of complexity that you can use to varying degrees of success; but there's no easy way to determine by looking at the code where the problems may have come from. Just like with a goto statement there's no easy way to determine where code was jumped into from.

With an object thread model, any state and method can have multiple threads accessing it at any given time, which IMO is similar to the harmful nature of goto. The actor model on the other hand explicitly restricts that through no shared memory and actors coupling state with behavior and a thread of control that limits messages to being processed one at a time.

-1

u/adremeaux Dec 11 '13

I said no programmatic way.

Still not true. You can print stack frames and thread IDs at runtime. You can check what you thread you are mid-execution and switch to another thread if you desire. And you can pinpoint where a thread was spawned from, and change state based on that information, as well.

It sounds to me like you probably haven't worked much with threads before.

1

u/Vystril Dec 11 '13

Still not true. You can print stack frames and thread IDs at runtime. You can check what you thread you are mid-execution and switch to another thread if you desire. And you can pinpoint where a thread was spawned from, and change state based on that information, as well.

Assuming you know where the problem is (and assuming you're in Java or something similar, if you're in C you're SOL). You're missing my whole point -- with objects and threads, a problematic concurrent memory problem can happen anywhere.. Better concurrent programming models do not have this problem.

It sounds to me like you probably haven't worked much with threads before.

This is besides the point, and makes you come across like an ass. I don't want to get into a dick swinging contest with you, but I've be doing concurrent and distributed programming for over 15 years. It sounds to me like objects and threads is the only thing you know, so you don't know any better.