Re: WSJ article on software liability

From: Traveler (traveler_at_nospam.com)
Date: 02/28/05 

Date: Mon, 28 Feb 2005 13:54:02 -0500

In article <4222EF57.E270394A@wecs.com>, Bryan Hoover
<bhoover@wecs.com> wrote:

>It might be helpfull if you could clarify (for me at least) a bit more
>about how your system compares with the idea of a thread of execution.
>For instance, according to my understanding, a simple combustion engine
>-- a motor -- has a single driver -- think, cam shaft -- and everything
>else in the system is driven on that -- the other elements don't have
>their own threads of execution, or drivers -- they are connected via
>gears essentially, to the single source drive, the cam shaft -- if it
>doesn't turn, everything else -- the water pump, pistons, fan, lifters,
>drive shaft, wheels -- stops moving as well. Likewise, the main loop of
>a traditional single threaded computer program. With a multithreaded
>application, it's like having multiple engines with the main program
>controlling, keeping them in sync so to speak.
>
>My cride understanding of a computer hardware system is that, similar to
>a combustion engine, there is essentially a single driver -- system
>clock (I think one would call it) on which everything else is driven --
>perhaps there's more than one clock, in which case I imagine, there is
>some system element providing for syncrhonization.
>
>Could you give a sort of compare and constrast of your system in terms
>of what's describe above? I think it would go a long way in helping to
>understand what you are proposing.

A COSA system has a single thread of execution, the execution loop or
microkernel. No other algorithmic code is allowed. Using your analogy,
one could say that the loop is single driver. The loop runs
everything. It is responsible for processing every element (cell) in
the system during any given cycle, as the need arises. A cycle is
virtual and is marked by a single virtual master clock. Every
operation performed within a cycle is considered concurrent.

The microkernel is really a necessary evil. Ideally, every element in
a COSA system would be self-processing (pretty much like a neuron in
the brain), obviating the need for a fast main processor to do the
work of many small virtual processors. BTW, this is not unlike the way
a neural network program or the cells in a spread*** work.

What makes COSA different from other synchronous reactive systems is
that every elementary operation (addition, subtraction,
multiplication, etc...) is a cell. Cells are divided into sensors and
effectors. They communicate with each other via signals. A program
consists entirely of sensors, effectors and their environment
(constants, variables, etc...). This organizational structure makes it
possible to solve the primary cause of instability in complex
algorithmic systems: unresolved data dependencies. This is because
sensors and effectors can be automatically coupled during development,
leaving nothing to chance. In an algorithmic system, by contrast,
resolving data dependencies is entirely the responsibility of the
programmer. The problem is that, in very complex systems, it is easy
to overlook critical dependencies. The problem is even worse when
legacy must be maintained by newly hired programmers who are
unfamiliar with the code.

Louis Savain

The Silver Bullet: Why Software Is Bad and What We Can Do to Fix it
http://users.adelphia.net/~lilavois/Cosas/Reliability.htm

Quantcast