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.
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?
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.
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
