Tuesday, August 21, 2007

COSA vs. Erlang

The functional programming language Erlang is rightfully touted by its supporters as being fault-tolerant. What they mean is that, in the event of a malfunctioning process (or even many processes) in a program written in Erlang, the other processes will continue to run properly. Erlang programs tend to fail gracefully rather than catastrophically. Contrast this with a program written in a conventional language like C or C++ where even a minor defect may result in a catastrophic failure that crashes the entire program. Fault tolerance in Erlang is due to its heavy use of concurrent processes and its strict reliance on asynchronous messaging between processes. Asynchronous messaging means that the message sender does not have to wait for a response from the receiver before continuing its execution. This way, if the receiver malfunctions and crashes, the sender can continue to perform its function, unimpeded. By contrast, synchronous messaging is what normally occurs in a function (subroutine) call, in conventional programming.

COSA shares all the fault tolerance qualities of Erlang but this is where the similarities end. The COSA philosophy is that nothing should fail, period. There are software applications where safety is so critical that not even extreme reliability is good enough. In such cases, unless a program can be guaranteed 100% reliable, it must be considered defective and should not be deployed. That’s the main goal of Project COSA: 100% reliability, guaranteed.

A COSA Object or Component

Unlike Erlang and other functional languages, COSA uses a graphical approach to software construction (see figure above) because the linguistic approach is not conducive to good program comprehension in a complex parallel environment. In addition, whereas a concurrent process in Erlang can be as long (both in number of instructions and in execution time) as the programmer desires, all processes in COSA are elementary and have equal execution times. This is what is meant by COSA using synchronous processes (cells), which is not to be confused with synchronous messaging. Thus a COSA program is based on fine-grained, synchronous parallelism. The end result is that timing is rigorously deterministic. This, alone, eliminates an untold number of timing-related bugs.

Synchronous processing is an essential characteristic of COSA but there are many other equally beneficial aspects from the point of view of reliability. These are explained on the COSA website. Do take a look. There are disadvantages, of course. For example, while Erlang is available now and can run efficiently on current processors, COSA is still in the development stage and must be interpreted on current processors. The reason is that COSA is inherently non-algorithmic and current processors are designed and optimized for the algorithm. Having said that, I feel that the advantages of COSA (e.g., total reliability) far outweigh the disadvantages. Eventually, the computer industry will get tired of the heavy price its customers continue to pay for unreliable software systems. At that time, it will come to its senses and build the right CPU architecture to handle the COSA model. When that happens, all the disadvantages of COSA will disappear and we will be able to build parallel software systems of arbitrary complexity without the accompanying unreliability. It will be the golden age of automation, which is the true promise of computing. It's worth the wait, in my opinion.

No comments: