Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×

Multi-threaded Programming Makes You Crazy? 166

Posted by Hemos from the doing-it-better dept.
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. "
This discussion has been archived. No new comments can be posted.

Multi-threaded Programming Makes You Crazy? More

Multi-threaded Programming Makes You Crazy?

Comments Filter:

  • Use the right tool (Score:4, Interesting)

    by AKAImBatman ( 238306 ) * <akaimbatman AT gmail DOT com> on Tuesday May 02, 2006 @10:21AM (#15244982) Homepage Journal
    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!

    • Re:Use the right tool (Score:2, Insightful)

      by lbrandy ( 923907 )
      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

      • Re:Ada (Score:2)

        by booch ( 4157 )
        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
        • it seems to me that Java doesn't give us a whole lot more than Ada had

          How about a runtime you can use on a cell phone?
          • It's not difficult to crosscompile an Ada compiler for embedded chips like ARMs and Xscale. This generally lacks certain featuers (ie, real time and threading)... but this is pretty trivial to get most of GNAT up and running on a major processor.

            The real problem comes in when there's some cutsom hardware with a co-DSP or something like that.. since these compilers are generally customized heavily for a specific language (ie, C).

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

      by Chuck Messenger ( 320443 ) on Tuesday May 02, 2006 @10: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 @11: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).

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

          This isn't necessarily true on multiprocessor machines. One of the extra things that mutexes do under the covers is execute memory barriers as needed to ensure the semantics are always what the programmer would expect. Without those barriers, even updates that are guaranteed to be atomic may be seen out

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

          So, if you're doing multithreaded programming with Java, you're "encouraged" to have helter-skelter mutexes (i.e. a mutex on each "structure", aka whatever-you-like-to-call-it). That's dangerous and inefficient. On a surface level, it seems kinds of nice. Because of that feature, you can say "Java is multithreading

          • You are perfectly free to use a single object as a mutex, shared between as many classes or threads as you want in Java. And of course, this includes making a single global lock if you want to. It's trivial to do.

            I have certainly never felt that java has "encouraged" me in any way to make lots of mutexes.

            • That's fine. But then, what feature of Java, that you make use of, qualifies it as a "multithreading-safe language"?
              • I haven't seen anybody around here except you claim that Java is a "multithreading-safe language". I can't even imagine what such a concept is.

                The only claims I've seen by others is that it is easy to do multithreaded coding in Java, because the language was designed with it in mind. For example, consider this:

                synchronized (myMutex) { ... }

                "myMutex" can be any object. "synchronized" is syntax. Only the thread that "won" the myMutex object will be running the code inside the braces; any other thread t

                • I haven't seen anybody around here except you claim that Java is a "multithreading-safe language". I can't even imagine what such a concept is.

                  Refer to the post to which I originally responded:

                  ...and get yourself a technology [sun.com] designed for multi-threaded programming.

                  What does that mean -- "designed for multi-threaded programming" -- except that the language itself has native capabilities to support multithreading? Java does have such capability, but my argument is that the native capability is in

                  • In short, C++ (combined with a decent underlying O/S and development environment) is just as much a "technology designed for multithreaded programming". There's nothing about support for multithreading which is particularly compelling about Java vs. C++ (that I'm aware of).

                    I would +1 the rest of your comment but must take exception here. The Java language standard makes useful sequencing and atomicity guarantees that make it clear exactly when a mutex is needed. C++ does not. A dumbed-down version (bec

                    • In Java, you can safely perform unsynchronized reads and writes to an int member variable without worrying that on some platform, somewhere, a thread might read garbage from that variable because of concurrency. (This statement dates to 2001; now I hear strange terms like "64-bit Java," so this might no longer be true.)

                      It is still true. Java guarantees the size of things like int no matter what the platform, and guarantees atomicity of accessing such variables. Of course, on 64-bit platforms you naturally

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

      • Take a look at java.util.concurrent (as another response has suggested). Specifically, look at:

        "Concurrent Programming with J2SE 5.0"
        http://java.sun.com/developer/technicalArticles/J2 SE/concurrency/index.html [sun.com]

        and

        "Concurrency Utilities Overview"
        http://java.sun.com/j2se/1.5.0/docs/guide/concurre ncy/overview.html [sun.com]

        There's much more to concurrency in Java (especially Java 5) than simple target-object synchronization. (For example, you can set up queues to pass safely from one thread to another.)

        You might also wa
    • 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
        • what does the level of parallelism have to do with it ?

          i give you a simple example, your application is using a third party library that you have not optimized for threading. the api contains a block like this :

          while (condition) {
          x++;
          }

          now imagine that you have shared the x between your threads and that it gets incremented 1000 times. this means 15 000 low level threading messages sent between the cpus that "yo you cpu, this equals now to this". the x may be buried into some deep hierarchy of structs
      • 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).

        I wouldn't recommend Python for work on multi-cpu systems. It has a global lock that means that only one thread may be executing python code at a time. Python only scales in a cluster-like fashion, not with big & fast systems.

        From the `popular` languages, php seems to be only one who is totally ignoring threading

    • Re:Use the right tool (Score:5, Informative)

      by stienman ( 51024 ) <adavis@@@ubasics...com> on Tuesday May 02, 2006 @11:18AM (#15245613) Homepage Journal
      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

        • What I don't like about Java's concurrency is a) it forces ALL objects to have a mutex/condition variable structure (stupid wasteful overhead), and b) the condition variable support doesn't allow you to do things like share a mutex for separate condition variables. Yes, it makes it easier to not screw up (by using the wrong mutex entirely), but it also takes away a lot of flexibility.

          For example, it is more difficult and less efficient to implement reader/writer interlock models without the ability to hav

    • 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
      • Yes, concurrency isn't a new problem, but saying that it has 'plenty of solution' is going way overboard IMHO.
        There are many ways to attack the problem true, but it remains a very difficult thing to do..
        Especially for 'normal' programs say a game engine which must be changed quickly because of a new idea, that is to say not 'multiplying two matrices' types of programs.
      • I agree, someone will probably throw a brick at me for mentioning MSVC/C++ but it libraries all come in thread safe versions and it is common practice in Windows to start a thread to efficently handle messages from such things as the service manager. Also casting off a thread for a lengthy operation resulting from an MFC button press ensures you dialog does not stop responding while it backs up the hard drive.

        I see alot of screwed up code because the coder did not understand the basics (granted the old/n
    • It might be the right tool for threads, but you can still allocate a semaphore in C, C++ or any language that can call out C code.

      It is most definitely not the right tool if you want to do anything outside the java VM. Sun seems to feel that their language should represent the lowest common denominator of system level functionality across all operating systems. Unfortunately that means that if you want to do anything at the system level you'll have to work around fundamental limitations in Java. And the m

    • Re:Use the right tool (Score:3, Informative)

      by fm6 ( 162816 )
      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
    • Java will give each thread its own cache of variables to prevent deadlocking on concurrent modifications.

      This is nonsense. Java has no per-thread cache of variables. I don't even know what you are misdescribing. I can only guess that it's one of these things:

      • Each processor has a cache of memory. It's for speed, not preventing concurrency bugs. In fact, it frequently causes bugs - when one processor reads a memory location to which another has recently written, the cache can mean that you get stale data
    • get yourself a technology designed for multi-threaded programming. Java will give

      .. will give you a headache. Java thread support is bad. Because you can only lock around the synchronized() block you can't unlock the lock if you call out from that block. And what's worse, is the way they deal with the problem is to introduce bloated java.util.concurrent.* packages. It would have been much better to start with a small simple ReentrantLock type class.

      Java is such a great langange it really pisses me off

  • 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 @10:23AM (#15244997)
    Are a little mad anyway ;)

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

    by Mortice ( 467747 ) on Tuesday May 02, 2006 @10: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 @10:28AM (#15245054)
    I was wondering what was this program was about. Fortunately, here is there website. http://nptltracetool.sourceforge.net/ [sourceforge.net]
  • 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 @10: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 @10: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 @11: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]

    • Re:Here's your problem... (Score:3, Interesting)

      by sakti ( 16411 )
      Realized that link wasn't as helpful as I remembered. But here are some other good general links that should get you going.

      http://en.wikipedia.org/wiki/Concurrent_computing [wikipedia.org]
      http://en.wikipedia.org/wiki/Message_passing [wikipedia.org]
      http://en.wikipedia.org/wiki/Actor_model [wikipedia.org]

      The E lang has some good documentation on concurrency, even if you don't use it.
      http://www.erights.org/elib/concurrency/ [erights.org]

      As does Erlang.
      http://www.erlang.org/download/erlang-book-part1.p df [erlang.org]
    • Many algorithms don't scale using a message-passing paradigm. They can be implemented and will produce correct results, but the overhead of passing around the messages overwhelms the benefits of parallelism. Message passing is fine for coarse-grain parallelism, but it's not practical for fine-grain parallelism.
      • This is a implementation/compiler issue. There is no real reason why message passing can't be as fast as shared-state parallelism.

        • Re:Here's your problem... (Score:4, Informative)

          by Kupek ( 75469 ) on Tuesday May 02, 2006 @01:14PM (#15246793)
          Yes, there is a real reason. Sometimes it's inherent in the algorithm that the amount of data that must be shared is impractical to send using messages. Parallelization does not come for free; there are communication costs. If the communication costs are greater than the benefit you get from doing the computation in parallel, then you get no benefit from parallelization. Message passing will always have more overhead than shared memory multithreading. Hence, shared memory multithreading allows you to exploit finer grain parallelism than message passing.

          Your point that message passing is generally a cleaner design choice is valid, but it's not always a practical option.
          • i think you are missing parents point (or what i infer to be parents point).

            if 'messaging' is a compile-time abstraction rather than a runtime library, then this copy only needs to be made if the caller maintains a reference to the data and may mutate it afterwards. think of it is compile-time cow. this property of 'linearity' (bad term) is very helpful in composing abstractions, but it doesn't need to cost.

            it's helpful to disambiguate the processor-visible data sharing model from the programming model. the
            • In my world, "message passing" implies that you're going to scale to multiple nodes. But my point still stands even on a single node. Calling it simply an "implementation issue" is naive, because I'm unaware of any languages, libraries or compilers that are sophisticated enough to completely remove the overhead of passing messages.
              • going back to the comment about disambiguation, i'm assuming here that we're talking about a shared memory hardware implmentation (a precondition for your 'scalable shared memory model' in the first place). and its its a tightly coupled distributed memory machine, then much of the overhead you're talking about is handled by the message passing hardware (especially if it can be handled by a polling model)

                and no, i'm not talking about MPI, which is basically imposssible to get any kind of static niceness out
                • it's not a trivial issue, but coming out with a blanket statement that 'shared memory scales and message passing doesn't' is what is naive.

                  That would be naive, so it's a good thing I did not say that. My point all along has been about granularity of exploitable parallelism, and that shared memory parallelism allows you to exploit a finer granularity. I said nothing about scalability. It's not always true, but in general, the finer the granularity you try to exploit, the less scalability you're going to get
                  • actually there is parallelism at all sorts of grain sizes, all the way down to instruction level parallelism and loop unrolling/vectorization.

                    but the interaction between grain size and the shared memory/message passing paradigms is much weaker than you suggest in theory. of course if you're talking about marshalling messages over ethernet clusters then i have to agree with you.
              • actually there is another class of machines which is shared-memory non-coherent. this breaks the programming model which you're apparently so fond of, but may provide a good middle ground. the synchronization primitives are implemented with atomic ops serialized by the target memory system. i dont think there has been much programming model work in this area.

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

    by blackcoot ( 124938 ) on Tuesday May 02, 2006 @11: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

  • I always use a monitor class with multithreaded programming; the class handles all the synching and nothing is shared between the threads. In essence, the monitor is a singleton and each thread makes a call to something like g_monitor.getwork(&work) and inside getwork() I do (in pseudocode) wait on mutex, get mutex, pop work off queue, release mutex, hand work back to caller.

    Googling doesn't get me a good link to post, but I know it's a common concept in multithreaded programming and has always worked f

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

    by valdis ( 160799 ) on Tuesday May 02, 2006 @02: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 @02: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.

Slashdot Top Deals

I tell them to turn to the study of mathematics, for it is only there that they might escape the lusts of the flesh. -- Thomas Mann, "The Magic Mountain"

Close