Re: Objects, processes, and encapsulation

["P.H.Welch" <P.H.Welch@xxxxxxxxx>]

Ian et al,

> I've just finished reading Meyer's chapter on OO and concurrency ...
> ...
> 1  Active objects are inconsistent with service provision
> Objects should provide services to others. Active objects take
> responsibility for scheduling upon themselves, and away from clients. The
> situation becomes "particularly delicate" when both client and server are
> active.

I'm afraid I haven't read Meyer's book ... still ...

Claim: "active objects" can be clients *or* servers *or* both *or* IO/PAR
components *or* ... of course they can!

There's no "particularly delicate" problem when building client-server
systems out of "active objects" ... we know how to build them safely!

And, sometimes, servers need to refuse client requests (when they know
they can't handle them - e.g. a buffer refusing input when full).  For
that, it's no much simpler if the servers are "active" and can take
such decisions - rather than passively accepting all requests and
sorting out the mess when the request can't be serviced (e.g. by just
dropping it - which leads to busy-polling - or by wait/notify mechanisms
- which are too hard (non-WYSIWYG) to program).

And, sometimes, it's right that servers have the capability to choose
for themselves how to schedule their clients - e.g. for fairness.  See
the classic bartender problem in Fred Barnes' occam animation:

   http://frmb.home.cern.ch/frmb/occam.html

I use the term "active objects" only when talking to OO people.  Otherwise,
I use the term "processes".  For my definition of this word, see slide 33
from the Powerpoint presentation ("Communicating Processes, Components and
Scaleable Systems") under the "JCSP Support Materials" section on the JCSP
web page:

  http://www.cs.ukc.ac.uk/projects/ofa/jcsp/

Briefly:

  1. a "process" strictly encapsulates some data structures and algorithms
    for manipulating that data;
  
  2. the data and algorithms of a process are private.  The outside world
     can neither see that data nor execute those algorithms!

Point 2 is why "processes" are very different from "objects" (whose
attributes we must treat as global variables :( :( :( even when "private"
- and whose methods are there to be invoked by anyone who can see it).

Then, we need to know that:

  3. processes interact with their envoronment by synchronising on events
     (e.g. channel inputs/outputs, barriers, buckets, CREW-locked data, ...).

where a crucial point is that processes do not interact directly with other
processes - only with named events.  That decouples things just right.

Finally:

  4. a network of processes interacting via (internal) events is itself
     a process (that interacts with external events).

And now we have stucture - layers of process networks - and can build
the universe!

> 2 Active objects clash with inheritance
> How do you inherit, and modify, an active behaviour? He criticizes
> Simula's "inner" construct for forcing a parent class to prepare the
> ground for offspring. A class should be "open" to modification, but
> "closed" upon use. Multiple inheritance exacerbates the problem.

Humm ... as someone mentioned, Tom's paper focusses on inheritance of
process (i.e. "active object") *interfaces* - which are just the set of
external events (channels etc.) with which it engages.  Inheritance of
process behaviour comes simply by reusing old ("super") processes intact
and modifying their behaviour by connecting them with some additional
ones.  [Actually, it's not quite that simple - hence his ideas on
splittable variant channels ...]

However, in JCSP (which has to make do with the existing Java language)
there is no problem with inheritance for process behaviour - using the
normal inheritance mechanisms.

A CSProcess has a public run() method supported by private or protected
support methods.  If you have designed your CSProcess for inheritance,
you just abstract those parts of its behaviour you wish to allow to be
modifed into protected support methods (invoked directly or indirectly
from run).  Then, it's obvious how to extend your CSProcess and modify
its behaviour.  Extending ALTs to include extra events for your extended
process is a little messy, but can be done - although the shell of the
ALT code (and loop) has to be rewritten (Oyvind's 2nd. talk at CPA-2001
would help here).

But ... I've never used Java inheritance in JCSP applications (and there
is little in the JCSP API itself).  We do get reuse, though, via plug/play
mechanisms along the ideas in Tom's paper.

Better go read Meyer's book I suppose ...

Peter.