Geoff Steckel wrote: > This discussion of threads is isomorphic to: > > Why do CPUs have MMUs? > Why don't we write "good guys' timeshared programs" which run > cooperatively and noninterfering in a shared unprotected > environment? > > Answer: it's too hard to write perfect programs. > Compartmentalized security simplifies each component and > drastically simplifies keeping the whole system > running well. > > Matthew Weigel wrote: > > Geoff Steckel wrote: > > > >> IMnsHO, threads should never be used unless absolutely > necessary. They > >> are very bad software practice: > >> they share data and resources in uncontrolled ways > > > > It's controlled by the code you write. > > That makes it implicit and/or accidental. Data sharing > between any parties must > be explicit and declared, otherwise it is either a bug now > or a bug later when the next maintainer doesn't know. > Accidental state sharing is by definition a fatal bug. Probably worse, since you cannot depend on the bug showing itself. There is a big difference between probably working and failproof.
> > > >> they encode state implicitly in the program counters of > the threads > > > > The hell? > OK, you're debugging a multithreaded program. Quick, what's the state > of all the threads now? Not encoded in data? Hmmmmmmmmmm.... how long > is it going to take to discover it. > > > >> they are extremely difficult to guard against external > conditions > >> such as unexpected incoming data > > > > Incoming from where? Incoming from all the other threads acting on common state, I'd think. In general, code goes from ---everything is consistent---- messing with internal state --- is not externally consistent ---everything is consistent (again)----- If the object is speeding thing up, the system should be ***inconsistent*** almost everywhere (time) Now it is entirely possible to work from inconsistent data and arrive at correct results, certainly **most** of the time. There seems to be some kind of belief that threads will somehow magically take care of whatever problems there are with lots of things going on at the same time. The effort that has gone into making libraries thread-safe wouldindicate otherwise. (Application code is done better than libraries???) > Any useful program does I/O. Otherwise the computer is a space heater. > So, other than pattern generators with built in data, every useful > program must take input. Any multithreaded program which I've observed > has some form of asynchronous inputs. Now, what happens when > an unexpected > datum arrives. > > > >> complete and correct error recovery requires complex and error > >> prone code > > > > Welcome to "non-trivial software development." > > That's exactly the point. Subtle but extremely important. > Every effort must be made to keep the software as simple as possible > so that it is comprehensible. Incomprehensible software is by > definition a fatal bug. > > And yes, error recovery is a very significant part of any non-trivial > useful program which does (for instance) network I/O, because the > universe of possible errors is large. Error recover? Does anyone ever debug error recover? Is there any way anyone **COULD** debug error recovery? on order of magnitude more complicated and no tools --- predictable. Maybe I'm overly pessimistic, but if so, (try to) prove me wrong. > > It's possible to write any program a (possibly infinite) > large number of ways. > Writing a debugged and maintainable program is much harder. > Doing it in a limited time is harder still. > Any construct which causes complexity disproportionate with the > total system gain (development & maintenance resources, run > time resources, > etc. vs useful output) must be avoided. > Threads are almost always such a costly construct. > > geoff steckel
