Slashdot Mirror
Fundamentals Of Multithreading
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."
I am the owner of SystemLogic.net, just to let you know, we officially got /.'ed. I'm trying to log in to the site now to take off a couple scripts in order to lighten the load but I can't get in.
Just letting you guys know I'm working on it.
ftp://plg.uwaterloo.ca/pub/uSystem/uC++book.ps.gz
It approaches the subject from a more theoretical rather than applied point of view, but if you understand all of the concepts in this book you will have a better working knowledge of concurent programming than 99% of the programmers in the industry!
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...
Is this, like, during midterms, when you're trying to study for all your classes at once?
Just junk food for thought...
Based on the description of the article, I looked up some things. What can I say? Somebody modded me down, so I'm at 49, and I'm incomplete without that karma point.
Amdahl's law
Amdahl's law
On chip multiprocessing
Simultaneous multithreading
If tits were wings it'd be flying around.
SMT is where you have one processor core executing several threads at the same time without having to context switch. The CPU maintains state (registers and flags etc.) for each thread and can execute instructions from each thread simultaneously down different pipes. This improves throughput as you don't have the overhead of task switching and you also have a far better chance of keeping your pipes full.
Naturally, it requires OS support for it to work, but most CPU manufacturers are looking to go this way in the near future.
Fear: When you see B8 00 4C CD 21 and know what it means
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...
The server appears to be slashdotted. Time to make up conversation while it recovers. ^_^
Reguardless of whether your system/OS has multiple processors or can handle multiple process execution, writing your code to be multithreaded might be a good design choice. If nothing else it forces and enforces abstraction and "compartementalize" of the design and code.
The one huge draw back to writting code that is multithreaded is the syntax baggage you must carry around and use to keep the system sane. Even in thread friendly languages Java where the language semantics try to help users write clean multithreaded code its still a non-trival thing to support. Bug can be very obscure and extremely non trival to solve in multithreaded code not to mention tools can become cumbersome(which stack am I asking for the value of "counter" on?).
Its too bad that writing threaded code is still considered to be an "advanced coding skill".
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/
...but I'm reading Slashdot right now, and I can't do two things at once.
more technical content, please.