Mailing List Archive Mailing List Archive
> Date: Tue, 14 Mar 1995 10:39:02 -0500
> From: Carl Heinzl <heinzl@sw*.st*.co*>
>
> Seriously though, allowing anything to run on one of these computers
> other than the task at hand would be asking for trouble, you now have
> a multitasking OS that has REAL TIME work to do. Think of it - how
> can you guarantee that a user wouldn't crash the machine? (this is
> possible, but it makes the operating system a LOT more difficult to
> write).
Agreed! This was an issue I tried to raise during one of the
computer sessions at tek, but I don't think I expressed it very
well then. It came out of a discussion concerning a device
called the Dive Tracker, which is a general-purpose submersible
computer with a lot of nice flexible capabilities. It's creator
mentioned that the user could load it with their own software
written in C, and someone also mentioned that it might be nice
to run dive profiling or gas absorbption software on it.
Everyone who works with C will realize just how easy it is to
munge pointers and trash memory, despite even the most talented
programmers' efforts to the contrary. All software has bugs,
and in a multitasking computer a bug in one program is sometimes
capable of affecting another program. Protected-mode operating
systems can help, but aren't foolproof and carry a significant
overhead. Tools (like Purify) are available to help catch some
bugs, but not all of them. Testing also is important but
imperfect. Therefore, when the impact of bugs is extremely
high (as with life-support software), it seems wise to try to
reduce the instance and mitigate the impact of bugs in other
ways as well, such as encapsulating components into independant
(and perhaps redundant error-cancelling) chunks that are each
as *simple* as possible. This almost certainly means separate
memory spaces and CPUs, and limited and well-defined interaction
with the other components.
Someone at tek pointed out that the redundancy that could be
attained by having two of these devices would address the risks
I described. I don't agree -- bringing two (or more) is a good
way to address "random" infrequent failures of a component, but
it would still leave one open to deterministic (though uncommon)
failure modes present in each of the identical devices. One can
envision a situation where exceeding a certain depth or time
would cause a program to overwrite an array bound, for example.
I have nothing at all against general purpose devices like
the Dive Tracker -- actually, I thought it was a really great
idea. I'm only concerned about mixing life-support software
and non-life-support software in a manner allowing significant
interaction between the two. Encapsulation is our friend!
p.s. I don't think anyone was actually suggesting that we go
down this route. However, as underwater computers become
increasingly flexible and powerful, the temptation is
going to present itself to wider and wider audiences...
Navigate by Author:
[Previous]
[Next]
[Author Search Index]
Navigate by Subject:
[Previous]
[Next]
[Subject Search Index]
[Send Reply] [Send Message with New Topic]
[Search Selection] [Mailing List Home] [Home]