David Higgs wrote:
On Feb 17, 2008 8:01 PM, Geoff Steckel <[EMAIL PROTECTED]> wrote:
Gregg Reynolds wrote:
On 2/17/08, Marc Balmer <[EMAIL PROTECTED]> wrote:
Geoff Steckel wrote:
Threads or any other form of uncontrolled resource sharing
are very bad ideas.
that might be true for those that don't understand threads.
for other it can be highly benefitial.
Indeed, "threads are bad" strikes me as just plain silly. In fact,
it's not even a technical issue; anybody who thinks it is is in for a
rude surprise (like, zero market share) in a few short years. It's a
"threads" is a particular programming model of multiple execution
contexts in a (mostly) shared memory and (mostly) shared resource
environment which is not cost-effective for producing reliable software.
Assuming that a software program is not system-critical or requires
high security, and it benefits greatly from a shared memory/resource
model, I fail to see why threading can not be cost-effective.
May I interpret this as saying "Threads are cost-effective in programs
which don't have to be reliable"? If so, what you're saying is
irrelevant to the argument I'm making.
As an aside, I prefer all programs I use to be as reliable as possible.
It is much easier to produce a reliable multithreaded application using
multiple processes and an appropriate communication method for sharing
the specific data needed.
"Easier" is hard to quantify when writing software. I've written
several programs with MPI that could have just as easily been written
with threads or fork()ed processes. IMHO, some tasks lend themselves
more easily towards threading than others, and others to multiple
processes.
The only programs which I can see which could possibly justify
threads are strict SIMD. Any other cases where threads are proposed as
an optimal solution strongly suggest a very sloppy partitioning of data
or functionality.
Any counterargument must speak to advantages the "threads" model has
over multiple processes or other protected multiple execution models
versus the increased cost of construction and maintenance of a reliable
program using the "threads" model.
Any argument to experience must be from similar actual implementations
using "threads" and another model, such as multiple processes with
interprocess communications.
Threads are hard to secure, this is commonly accepted as true. It
does not logically follow that OpenBSD should entirely disallow the
use of threads (or any other valid programming model) in software.
That would significantly hinder adoption of OpenBSD for general
workstation use.
I would disallow userland threads in any program which is critical to
security.
The availability of threads to userland programs shouldn't hurt any
program that doesn't use them. OpenBSD developers are unlikely to
introduce threaded features to userland tools without a clean bill of
health from code audits, even when the changes are trivial.
Using 'goto' and 'snprintf' in C software are also considered
potentially harmful and easy to misuse. But OpenBSD does not limit
their use; they CAN be used correctly and without error. The same
applies to threads: only when appropriate. Since you (presumably) use
OpenBSD, I hope you trust developers to decide when threading is and
is not appropriate.
In C, goto cannot be used non-locally.
C is vulnerable to buffer overruns. That requires vigilance. However,
the scrutiny needed to ensure snprintf and the like are not a problem is
also local.
Threading is a non-local vulnerability.
I trust the paranoia of the developers. It is well justified.
