Stories
Slash Boxes
Comments
Search

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

Multi-threaded Programming Makes You Crazy?

Posted by Hemos on Tue May 02, 2006 09:18 AM
from the doing-it-better dept.
Programming
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. "
+ -
story

Related Stories

[+] Technology: Donald Knuth Rips On Unit Tests and More 567 comments
eldavojohn writes "You may be familiar with Donald Knuth from his famous Art of Computer Programming books but he's also the father of TeX and, arguably, one of the founders of open source. There's an interesting interview where he says a lot of stuff I wouldn't have predicted. One of the first surprises to me was that he didn't seem to be a huge proponent of unit tests. I use JUnit to test parts of my projects maybe 200 times a day but Knuth calls that kind of practice a 'waste of time' and claims 'nothing needs to be "mocked up."' He also states that methods to write software to take advantage of parallel programming hardware (like multi-core systems that we've discussed) are too difficult for him to tackle due to ever-changing hardware. He even goes so far as to vent about his unhappiness toward chipmakers for forcing us into the multicore realm. He pitches his idea of 'literate programming' which I must admit I've never heard of but find it intriguing. At the end, he even remarks on his adage that young people shouldn't do things just because they're trendy. Whether you love him or hate him, he sure has some interesting/flame-bait things to say."
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Multi-threaded Programming Makes You Crazy? 50 Comments More /

 Full
 Abbreviated
 Hidden
More
Loading... please wait.
  • And of course, as soon as I add traces, problems disappear... Don't panic! Calm down and take a deep breathe...

    ...and get yourself a technology [sun.com] designed for multi-threaded programming. Java will give each thread its own cache of variables to prevent deadlocking on concurrent modifications. If you need to do something that requires more than one statement (thus creating a race condition), then you need to create yourself a semaphore-based lock:
    synchronized(objectToModify)
    {
        if(objectToModify.getX() == myObj.getX()) objectToModify.setY(myObj.getY());
    }
    Of course, such synchronizations can carry a huge penalty on multi-CPU systems. i.e. If you manage to stop every CPU, you could be wasting MASSIVE amounts of CPU time. As a result, you should always strive to push locks down as far in the code as possible. They must execute extremely quickly, and should only be called when absolutely necessary. Follow those guidelines and you'll find it fairly easy to write multi-threaded code.

    Oh wait. I was supposed to praise the NPTL tool, wasn't I. Um... well... it's very nice. And they've got... um... penguins on the homepage. Oh, and look! It's GPLed! Wow. Just... um... wow. Hey, did you know that the author of Minix wrote a book [amazon.com] on OS Design? Really. It even covers the basics of multi-threading. It's pretty cool, you should... um... check it out. Yeah, that's the ticket!
    • 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...
      • Funny I have never seen this donkey show of which you speak but there is nothing wrong with java. Ada is an interesting language. It was supposed to be the next big thing back in the early 80s since the DOD was going to make it a standard. It never really caught on in the US outside of the military.
        I think that was because of a lack of good, cheap and or free tools. Back in the early 80s you could buy Turbo Pascal, Turbo C, and Turbo Basic for under a hundred dollars each. Then came Microsoft's Quick Basic
      • Man, I wish I still had mod points to give you.

        Ada was considered a BIG language when it came out. Big as in complexity. The C++ folks used to make fun of it. That's before they added templates to C++, which makes Ada look simple by comparison. Ada also came with a large set of libraries. But nowhere near what Java now comes with standard.

        Anyway, when I first started learning Java, I thought that it was almost more similar to Ada in spirit than C or C++. The set of libraries seemed similar, as well as the m

    • Java no panacea -- must know what you're doing (Score:5, Informative)

      by Chuck Messenger (320443) on Tuesday May 02 2006, @09:51AM (#15245293)
      Java's "builtin thread saftey" is simply a poor hack. The idea is to give _every_ structure a mutex. Any access to the structure requires a mutex lock.

      First off, that in itself will not prevent deadlock. Secondly, it's damned inefficient.

      Look: there's just no way around it. If you want to do effective (i.e. low bug, high performance) multithreaded programming, you simply have to understand what you're doing. Ultimately, the tools of your trade will be mutexes, condition variables, semaphores, etc -- the O/S primitives. Don't rely on your programming language to "automatically" use these for you, blasting out mutexes machinegun-style. Instead, figure out the logic of your program. You probably need only a small number of mutexes.

      A key to effective multithreaded programming is to adhere rigidly to certain programming practices. It must _NEVER_ be the case that 2 threads have write access to a given item at the same time. Duh. But you can use fancy programming tricks to, in effect, automatically add run-time assertions to your code which assure that this practice is being adhered to. In production mode, you remove these runtime assertions.

      Another good practice is, if you really need to have multiple mutexes, to arrange them into a hierarchy. When a top-level mutex is locked, no other mutex can be locked. When a second-level mutex is locked, only top-level mutexes can be locked. Etc. This hierarchy can be verified at runtime, in debug mode. Adhering to this regime will go a long way to removing the possibility for deadlocks.

      Bottom line: you really have to know what you're doing in order to write good multi-threaded code. You should take the time to really study that problem space. An excellent book I've found for this purpose is "Concurrent Programming in ML". (I know -- nobody uses ML. So what? Learn the language just for the purpose of understanding the book. Then, you can apply your knowledge to any domain you're working in).

      • Re:Java no panacea -- must know what you're doing (Score:5, Informative)

        by 0xABADC0DA (867955) on Tuesday May 02 2006, @10:16AM (#15245598)
        No, Java does not give every structure a mutex (as if Java even had structures). It only creates a mutex if synchronization is used on an object, so if you never use locking there are no locks. And no, it is actually perfectly fine for 2 or more threads to have read or write access to the same variable as long as it's atomic read/write... you just have to know what that means for your program.

        Batman was right that after using Java's threading this NTPL trace looks pretty lame. Not only is the threading and locking in Java braindead simple, but the JVM actually tells you what is wrong. For instance it detects deadlocks and gives you the complete call trace of each deadlocked thread.

        Other languages have good locking too (ruby for instance), so it's more that everything is difficult and crappy in C and its kind. I guess if you are stuck writing a threaded application in C in the first place this tracing library could be useful. Of course if you use the heap you're going to also want to replace malloc/free with a fast multithreaded version and then do a bunch of hacks so that it isn't ridiculously slow (locking on every free()... now *that's* inefficient).

            • Yes what you say it true, but these are all implications of atomic read/write... It follows logically from having caches

              Umm, no, it has nothing to do with atomicity, nor is it because of caching.

              Atomicity just guarantees that the atomic change is seen fully or not at all. It makes no guarantees about what other changes will be seen. And the problem doesn't have anything to do with caching, assuming the caches work properly (and they do). The caches maintain coherency as needed between each other and

              • First, the compiler may reorder things.... The compiler may choose.... Compilers take care.... Even if the compiler doesn't reorder like that, though, the processor might.... the memory management unit *also* reorders writes.... I think it's the concept that's hard.

                None of these things are given; there's no such thing as "the concept." The designer of the language decides what guarantees to give the programmer and what latitude to give to the compiler, as well as what structures are provided to mana

      • It must _NEVER_ be the case that 2 threads have write access to a given item at the same time.

        Two clarifications:

        First, it's okay to allow multiple threads write access as long as the writes are guaranteed to be atomic and as long as the order of atomic writes doesn't matter. In practice, that second restriction usually means you need locking.

        Second, it's often important that one thread not be writing an object while one or more threads are reading it. In other words, multiple writers aren't the only problem.

    • 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
      • 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 ?

        Not always. If the level of parallelism is very fine, then the synchronization costs would overwhelm any gains from running in parallel. I really don't understand your overall point, either. Running a scalable multithreaded app over as many CPUs as possible is exactly what you wa
    • Use the right tool

      The correct tool is called a brain, but first the brain must be configured properly.

      Deadlocks are one symptom of poor program logic, and are designed into the program due to lack of proper controls. They frequently occur when a program is not designed before it is written.

      See "dining philosophers [google.com]" for an explanation of this, and several methods to prevent this situation.

      Tracing tools are all well and good, but if one starts out with correct logic in the first place then one won't spend more time debugging than programming.

      Always remember that a digital computer is a logical computing device. If you give it a series of instructions which do not ALWAYS have a logical solution, then it will choke ... eventually.

      -Adam

    • There are some good tools for the job. Relatively speaking, Java isn't one of them.

      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. Thus it suffers from the same weaknesses, including deadlocking, and potentially also things like potential priority inversion, depending on how clever the implementation of the concurrency tools is.

      If you want serious m

      • 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

    • You're right! It would be better to get a technology designed for multi-threaded programming. But then you go on to push Java? I'm confused.

      Now, granted, Java does provide builtin support for concurrency. Although that support is an implementation of the 30-year old monitor [wikipedia.org] concurrency primitive, which even one of its principal inventors (Tony Hoare) long ago abandoned in favor of better things [usingcsp.com]. Not to mention that Java's implementation of monitors is known to be broken [brinch-hansen.net] (or at least was - maybe they've fix

    • Single statements in Java are not atomic. You should use locks even on single statement operations. There is no guarantee that you won't get interference, otherwise.
    • 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. "Principle
    • If you're going to tout Java as a concurrent programming platform, the books you should link to should be about Java. Such as:
      • Concurrent Programming in Java: Design Principles and Pattern (2nd Edition), by Doug Lea.
      • Java Concurrency in Practice by Brian Goetz, Tim Peierls, Joshua Bloch, Joseph Bowbeer, David Holmes, and Doug Lea.
      • Effective Java Programming Language Guide, by Joshua Bloch. Though this is a general programming guide, its chapter on Threads contains es
          • volatile - causes a read or write out to main memory, ie, not the local CPU cache.

            Not even that, actually.

            In C, it tells the compiler that the read or write to memory can't be reordered. If you do a read, it has to get it from memory right then, rather than reusing one from before that it might have stuck in a register. It doesn't tell the CPU anything about synchronizing its cache or executing the instruction in order, however. You've gotta have both.

            In Java, it actually depends on the version of the

  • It looks like it's just a link to a sourceforge project... was there supposed to be something else?

  • All good programmers... (Score:5, Funny)

    by Nephroth (586753) on Tuesday May 02 2006, @09:23AM (#15244997)
    Are a little mad anyway ;)

  • Multi-threaded Programmation Makes Me Crazy? (Score:4, Funny)

    by Mortice (467747) on Tuesday May 02 2006, @09:23AM (#15245005)
    No, this title does. Is a Sentence? Is a Question? Why There a Space Before the Question Mark? What 'Programmation'?

  • Link to the home page would be nice (Score:5, Informative)

    by technoextreme (885694) on Tuesday May 02 2006, @09:28AM (#15245054)
    I was wondering what was this program was about. Fortunately, here is there website. http://nptltracetool.sourceforge.net/ [sourceforge.net]
    • Sadly, even the project's home page has spelling errors. I'd be willing to take a look at the project in the future if the original /. posting (which is full of blatant spelling and grammar errors) didn't come from a core developer of the project, but even the project's home page hasn't been checked for spelling or grammar errors at all.

      I agree that a spellchecker is not the end-all of looking for mistakes (their vs. there and so on aren't caught), but for the developers of the project to put "developper"
    • Fortunately, here is there website.

      Here is there?... then where is there?
      Here?
      What happened to there?
      Who's on first?

  • Slashvertismentation.

    These words are fillers.

  • Looking at the list of functions that it hooks into, I don't see pthread_rwlock*. Are the pthread_rwlock functions implemented using other pthread_* funcs? I haven't run into any problems yet with the project I'm working on, but it would be nice to run through this and make sure everything's working as expected.

  • ...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.
  • 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?

  • Bah (Score:3, Informative)

    by grindcorefan (959282) on Tuesday May 02 2006, @09:52AM (#15245299) Homepage
    Aha, so I can only do multithreaded programming on GNU/Linux with NPTL'ed glibc or what? Other programming langunguages than C/C++ don't exist or don't do threading. What about other operating systems? Specific solutions to general problems only apply to specific manifestations of the general problem and are therefore useless for most of us.

    The only good general advice about learning how to develop software on distributed systems I can give is: Read some of Andrew S Tanenbaum's books about operating systems and distributed systems in particular. The books contain knowledge you'll be able to apply to almost every system you develop software for.

  • Why all the negativism in the posts? (Score:5, Insightful)

    by kclittle (625128) on Tuesday May 02 2006, @09:55AM (#15245350)
    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.
  • No screenshots???!!!!
  • Moshe Zadka said it [kuro5hin.org] better than I ever could.

  • Multithreaded Haiku (Score:3, Informative)

    by pauljlucas (529435) on Tuesday May 02 2006, @10:25AM (#15245679) Homepage Journal
    There was a time when I was doing a lot more multithreaded programming (using the pthreads API, FYI). At the time, I was inspired to write some Haiku:
    Threaded programming
    is not for the faint of heart
    or for the sober.

    A small locked mutex
    mistakenly left alone
    results in deadlock.
  • I got several concurrent threads that write the same variable!

    Here's your problem. Shared state/variables is the anathema of good concurrent programming.

    Here's a good place to start if you want to learn a better way...

    http://www2.info.ucl.ac.be/people/PVR/bookcc.html [ucl.ac.be]

  • valgrind used to be able to do this (Score:3, Insightful)

    by blackcoot (124938) on Tuesday May 02 2006, @10:33AM (#15245769)
    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?
    • 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 consciousl

    • At my previous company we built a system with on the order of 10 threads working on a combined dataset consisting of many hundreds of thousands of objects and occupying a couple hundred meg of memory in a large installation. There could be hundreds of thousands of instantiated locks in the system, although they fell into maybe 30 classes of lock. The large number of objects and locks was manageable because there were a small number of objects (say on the order of 25) that modeled something in the real world

  • How Ironic.... (Score:3, Interesting)

    by valdis (160799) on Tuesday May 02 2006, @01:09PM (#15247304)
    Slashdot reported the summary line thusly:

    Developers: Multi-threaded Programming Makes You Crazy? 79 of 78 comments

    What's wrong with this picture?

  • Explanations... (Score:3, Informative)

    by gduranceau (970561) on Tuesday May 02 2006, @01:18PM (#15247392)

    Firstly, I apologize for my English (I'm doing my best).

    I perfectly agree with some of you: this article is a slashvertisment! The main reason for that is that I previously tried to submit something more descriptive, but it was rejected. That's why I tried again with a slightly different style.

    This tool [sourceforge.net] (PTT) inserts trace points into the NPTL to help you to analyze multithreaded applications behaviour. He's not designed for beginners, but for people facing complex multithreaded issues. I also agree with some of you: you can use Java or some others high level languages for programming. But some applications require performance and have to be written in C. That's why PTT can be useful for some developers.

    PTT has been presented at the Ottawa Linux Symposium last summer. You can find the paper here [linuxsymposium.org] (NPTL Stabilization Project, page 111).

    Regards...

  • A debugger won't help you if you're trying to ensure correctness at too low a level of abstraction. Most languages give you a couple of low-level building blocks equivalent to the pthreads basics: threads, mutexes, and condition variables. These should not be used directly except in the simplest of circumstances. Rather, they should be used to create a set of higher-level tools that can be applied in a simple and straightforward way to your task.

    The most popular way is to create a workflow model with task queues, worker threads, and job dependencies, plus a few application-specific rules to ensure that resource limitations don't cause deadlock.

    The high-level model can typically be lifted right out of your proof of deadlock avoidance. Don't have one of those? It's a good idea. The proof gives you a minimal solution and confidence to implement it. Without the proof, you're going to overkill the problem out of nervousness, and you still might miss something crucial.

All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-2009 Geeknet, Inc.