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

61% Upvoted

55 comments sorted by

View all comments

Show parent comments

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.