On Wed, 15 Nov 2006, Derek Smithies wrote:
I cannot resist on this. Sorry, but I cannot resist at all.
No problem, I enjoy a good rant myself..
Not everyone agrees - threads are inevitable. One very good arguement is found in http://www.gotw.ca/publications/concurrency-ddj.htm
Yip, multi core CPU's are inevitable. But if you multi-process instead of thread you can map your program onto multiple distinct CPU's as well. I have a nifty little script that scans 2000 object files starting at the 10 or so thread entry points and looks for non-reentrant intersections in the call graphs. You know something? Even the best developers are pretty lousy at getting threading right.
My personal view that when I hear developers say "threads are bad" is that the developer is actually saying a) gdb is a poor tool for debugging threads
Hmm, truish. I would rather say an arbitrary highly concurrent system is intrinsically hard for mere humans to grok, __unless_some_highly simplifying_architectural_design_choices_are_made__. We mortals are just not made with a good grip of multiple almost simultaneously occurring events. Of the simplifying design choices one can make, the most obvious two are the select / event loop architecture, and the forks & pipes architecture. The reason I say mmap/fork is a reason not to do threads is threads were introduced to us by Microsoft as "light weight processes". What Microsoft never mentioned in all its hype about light-weight processes is that Unix had long had better lightweight processes thanks to mmap, cow and fork.
c) the developer has never been forced to learn and undertand threads, so (out of laziness perhaps) never wants to use threads.
Partly the only thing to understand is you have to make some harsh simplifying design choices and stick rigorously too them. Cow and fork assists with that. I'm always amazed at how many people will tell me, "But the chances of those two events occurring within such a infinitesimal window of time is just not worth bothering about!" And then I explain to them since that thread has this priority, and if we're blocked waiting for this, as soon as we come free, we hit that infinitesimal window with probability one. Somehow when it comes down to the nitty gritty of instruction scheduling, pointer aliasing, and the volatile keyword, it seems to be one two a hard step for people to go from, "This is a very unlikely event", to "Murphy's Law is actively hostile", to designing threaded systems that are robust against _all_ and every possible sequence of events. John Carter Phone : (64)(3) 358 6639 Tait Electronics Fax : (64)(3) 359 4632 PO Box 1645 Christchurch Email : [EMAIL PROTECTED] New Zealand
