Slashdot Mirror

← Back to Stories (view on slashdot.org)

Fundamentals Of Multithreading

Posted by Hemos on from the the-tapestry-of-programming dept.

Bob Moore writes "SystemLogic has got a very thorough article on multithreading. Deals with Amdalh's Law, Latencies and Bandwidth, On-Chip Multiprocessing, Course-Grained Multithreading, Fine-Grained Multithreading, Simultaneous Multithreading, and Applications Of Multithreading. This is definately a good one."

3 of 122 comments (clear)

  1. Value of a Multithreaded Programmer by bjb · · Score: 5
    I can't tell you how many people I've worked with over the years who have either no idea on what or how to write multithreaded programs or they claim that they can, but in practice they end up writing code that isn't thread safe.

    I can say that as a programmer, my value is significantly increased by being proficient in multithreaded programming (beyond Java, FWIW). If this article sparks any interest in people, do read further and practice, practice, practice! The people that I've interviewed in the past who have a strong working knowledge of multithreading get a lot of points in my book, and I'm sure other "aware" employers do the same.

    Keep in mind, however, that just knowing how to launch a thread isn't enough. If your code isn't reentrant and thread safe, launching a thread isn't worth a damn.

    Good article... now if I could only get to it ;-)

    --

    --
    Never hit your grandmother with a shovel, for it leaves a bad impression on her mind...
  2. Re:First Rule by be-fan · · Score: 5

    Any programming construct can be harmful. Pointers, explicit memory allocation, anything! However, if interfaces are clearly defined, and and the code is kept simple (ie. lack of feature creep, something that the "new" (GNOME, KDE, etc) UNIX guys don't seem to understand) threading is just as harmless as pointers. I'm not going to get theoretical here, but I'll give you an actual example: BeOS. Say what you will about it being dead or the company being stupid or whatever, it has a kick-ass threading implementation. The app_server regularly runs with 60+ threads and the damn thing only crashes on me when I'm playing with a kernel driver. The apps, too, are stable, even though they are forced into using multi-threading due to the GUI architecture. If you want to see why this is the case, take a look at the BeBook (the API). Every time there is a possible thread interaction, they warn you about it. Just as you have to keep memory ownership clear, you have to do the same thing for threads. Theoretical rules aside, an entire platform begs to differ with you.

    --
    A deep unwavering belief is a sure sign you're missing something...
  3. Re:Simultaneous Multithreading? by Wesley+Felter · · Score: 5

    The processor doesn't switch at all; it actually runs multiple threads at the same time (hence "simultaneous") because it has a separate set of registers for each thread.

    More info: http://www.cs.washington.edu/research/smt/