---- John Carter <[EMAIL PROTECTED]> wrote: > 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 >
What situation would require the use of a thread? As in there is absolutely no other way to write this code or if it is coded without threads the code will take a million years to execute.
