Multi-threaded Programming Makes You Crazy?

gduranceau writes "Help! My program deadlocks! I got several concurrent threads that write the same variable! Everything goes well on my mono processor but becomes an incredible mess on that 16 CPU monster! And of course, as soon as I add traces, problems disappear... Don't panic! Calm down and take a deep breath. "

Re:Use the right tool

[lbrandy]

Why use Java when you can use Ada.... very good threading capabilities, builtin support for atomic operations... fast and clean.

And the best part is you avoid that feeling... ya know.. much like that time you saw the Donkey Show in Mexico on Spring Break... that really strange feeling you get when you use Java... and no matter how much you shower... it just won't wash off...

May I be the first to ask...

[carlos92]

...what's so original about this issue, that deserves to be posted to Slashdot? There isn't even a FA! If the guy wanted to publicize his work (he is a developer for the linked SF project), he could at least have written an article with a concrete problem (even if the problem was made up in order to show the solution), not just some generic rant about how tricky multithreaded "programmation" is.

More Info on the Home Page?

[soloset]

You can probably get a better idea of the purpose of the program on their home page (click the link in the menu of the sourceforge page that says, "Home Page").

Not sure why they didn't link directly to it?

Why all the negativism in the posts?

[kclittle]

Developing multithreaded is infact difficult, and any tool claiming to make it easier is worth looking at. If it works, these guys have done us all a favor. If it doesn't, at least they've made an attempt, and it may inspire others to do improve on it. Better tools are always welcome.

Re:Use the right tool

[moro_666]

I agree, java has great tools for avoiding deadlocks and great tools for multithreaded programming. But i have still seen people who manage to create incredibly bad code on java in multithreaded environments and also people who don't take advantage of the threaded design of the language at all :)
  Java has a noticeable initial coding and running overhead, but while the application starts to grow, it fades away. The only *free* and open alternative in these terms is python, which somewhat provides the same capalibilites but is somewhat limited on other features (network class loading as one example). C# i don't consider free, sure mono is free, but mono isn't pointing out where C# is going tomorrow, there's a redmond company who is giving orders on that one. Ruby just lacks performance, perl's threads aren't that complete (serious problems with objects and streams).

  The language itself doesn't really solve the problem. Educating the programmers does. It is even possible to write an (i)threaded perl application and get it running across boxes. From the `popular` languages, php seems to be only one who is totally ignoring threading and just focuses on having a single process for it all.

  However, for the program author, why exactly are you running a threaded app across 16 cpu-s ? I know lagging behind the synchronization of caches between 16 cpu-s is fun but wouldn't it be way more efficient to have a forked application instead that just send messages across to synchronize the data you really need to share ? Pulling data out of registries and pushing it in all the time doesn't seem to brightest idea of the day.

  From the ideological point of view, threading is a nice idea how to deploy an application, but if you run across many many cpu-s, threads in real life aren't so perfect anymore. They are close though.

In no way i claim that the information provided above is the ultimate truth, but it should be rather close ;)

valgrind used to be able to do this

[blackcoot]

http://valgrind.org/ [valgrind.org] used to include a tool called hellgrind for finding just such problems. unfortunately, hellgrind has gone away for a bit (it broke when the VM was re-done to support non-x86 platforms), but julian & co are working hard to get it working again Real Soon Now (tm). if you're using x86, you can use an old release of valgrind (2.2.0 i think) and you should be fine.

personally, i can't say enough good things about valgrind. there are a couple non-obvious issues (support for sse/sse2/sse3 is still in the works, so if you get an inexplicable SIGILL, this is probably the problem), but it's saved me hundreds of hours over the past year (and i'm sure it'll save me even more in the future).

that all said, my (admittedly limited) experience with threading is that it's best to design the deadlocks away before you even touch the editor. i wonder if there are any design tools which support deadlock / contention checking at the model or design level?

Re:Use the right tool

[Stocktonian]

I'm shocked, just shocked! All this time I thought programming was for the masses and it turns out that when you just copy stuff books and websites, it doesn't always work.

Really when are people going to get over this multithreading problem? Concurrency issues have been around for years with plenty of solutions for those who bother to learn about the principles.
While the parent poster mentioned Tanenbaum's Minix book with his tongue in his cheek, I think it's actually a very good introduction. "Principles of Concurrent and Distributed Programming" by M. Ben-Ari is also worth a read for anyone serious about programming these days.

No that's just common sense.

[Valdrax]

that all said, my (admittedly limited) experience with threading is that it's best to design the deadlocks away before you even touch the editor.

That's not "limited" experience. That's common sense. Trying to find deadlocks, race conditions, and accidental serialization in an application by experimentally compiling and running is like trying to build a house by nailing the boards together only after they've collapsed on you.

Seriously, threads cannot be bolted on as an afterthought. You have to consciously design threads in in the first place, and if you ignore this advise and attempt to retrofit your code, then you must audit the code fully first to see where execution can be grouped into the smallest safe units for locking.

I've seen what happens when you ad hoc threading in large library that was never designed to be reentrant. Worse, I've seen what happens when you get it working on Windows but fail to realize that the UNIX version never was successfully locking the library for 3-4 years before a customer tried to build an aggressively multithreaded app on top of it and only then discover all the deadlocks that lay hidden inside.

Re:Use the right tool

[Doctor Memory]

While Java does include some built-in support for multithreading primitives, its underlying model (using locks on data to prevent simultaneous access) is the same as many other mainstream languages today.

In other words, Java provides built-in support for traditional concurrency methods, rather than making you reinvent that particular wheel. Which means that if you've done multi-threaded programming before, Java probably supports whatever techniques you've (presumably successfully) used. I fail to see how this is the bad thing that previous posters seem to make it out to be. I don't think anyone is saying that Java has some wonderful new mutithreading paradigm, it just provides support directly within the language for threads and basic concurrency control. Yes, I'm sure there are better things out there, but the point is that Java is a mainstream general-purpose language with threading support. How many of those are there?