[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: OO and CSP (and real-time requirements)
> 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
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.