RE: OO and CSP (and real-time requirements)

["Campbell, John" <John.Campbell@xxxxxxxxxxxxxx>]

Hi Ruth


> At 09:23 13/10/00 -0600, you wrote:
> >What are the performance implications if you allow object-to-
> >object channels?  At the top level, the concept doesn't seem
> >difficult, but at the system implementation level, the implied
> >handshaking between all participants in an event would
> >require a combinatorial expansion of low-level communication,
> >wouldn't it?
> 
> As I see it, an object ( in the C++ sense) is a poor man's 
> occam process, 
> so there is no issue.

As I see it, Occam's (and CSP's) emphasis is 
on controlling system dynamics, with crude 
abstractions for data. Java/C++, on the other hand 
have crude facilities for controlling concurrency,
but sophisticated abstractions on the the data.  
(Mind you, I haven't necessarily accepted the 
approach, but I think that's what the proponents 
of OO were attempting.) 

>   In the occam/CSP process view, an object is a process. It's 
> interface is 
> defined in terms of a set of channels over which data flows. 

The crucial characteristic (IMHO) of OO objects is 
that they are created 'on-the-fly'.  Occam 
processes are compile-time defined and live 
until the program dies. True?

Now, you could envision an Occam/CSP system 
where, at run time, sub-systems are spawned 
off with internal events and shared events 
for interacting with the existing system.  
Channels would be dynamically created, used, 
and extinguished.  That's the kind of system 
you'd have if OO objects communicated with CSP 
protocols.  It sounds a little bit like the 
descriptions of the Pi-calculus I've seen 
mentioned in this community.

> Both types of objects can have multiple instances. However, the occam 
> version has a significant advantage. It is possible for the 
> object to do 
> things itself. It is not reliant on some thread of control 
> reaching it from 
> some other part of the program.

Its true that the thread control (in java/c++) 
gets pushed off to the programmer because of the 
primitive nature of the system facilities for 
controlling concurrency.  It seems simpler in 
Occam (IMHO) because of the discipline of the 
CSP protocols.  

But those protocols potentially involve communication 
accross the entire system.  The handshaking to determine
whether to engage in an event must involve all processes
that have the event in their alphabet, and other processes
that may have overlapping alphabets.  In a dynamic system
with no fixed number of participants, it seems like there
is no upper bound for the hand-shake.  Hence my concern that
real-time requirements may not be compatible.
 

-jc