Musings on occam and Java

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

Dear All,

I've been having some side communications with Gerald Hilderink about points
raised by his paper ("Concurrent Programming in Java").  Some things have
come up (e.g. about the `real' nature of object-orientation) that I would
like others to have a go at ... hence, enclosed is my latest mailing to
Gerald ...

Cheers,

Peter.

(cut here)
------------------------------------------------------------------------------
//{{{}}}

Gerald,

Thanks for your reply the other day on my comments on your paper.  Please
don't be alarmed by any aggression in my replies ... defending occam has
made me too nervous these days!  Your paper is valuable and needs to see
the light of day quickly ... here are a few more comments prompted by your
reply ...

//{{{  language constructs

You are right ... occam certainly needs strengthening.

To me, what it needs most is a library (or `package') mechanism burnt into
the language ... that would make life easier for every application area.

For non-embedded application (e.g. for compilers, operating systems, ...),
recursion and dynamic workspace allocation *may* be helpful.  Throughout
the 1980s however, most people worked with the occam compiler written in
occam and an integrated development environment (the TDS) also written in
occam ... in fact, I still use those tools.  The first occam system I used
(back in 1984) was on a Sage/Stride system, for which the TDS provided the
entire operating system (controlling all discs and peripherals).  The code
for this compiler/TDS was a collection of communicating processes and very
elegant.  We need to get back to this one day ...

You mentioned that you can create occam behaviour in Java (or C++) but not
the other way around, because occam lack certain language constructs.  Apart
from the above points, many in the occam community would say thank-goodness!
(:-)

//}}}
//{{{  object-oriented versus object-based

Peter Wegner's classification of object-based/class-based/object-oriented
are, of course, quite arbitrary ... but I guess that classification is
what the `object-oriented' community uses so we ought to stick with it.

But it remains slightly annoying that a system, that (to me) is implemented
with algorithms that are decidedly not oriented to the objects being
manipulated, gets classified `object-oriented' simply because it is written
entirely with objects, classes and inheritance!  I must write a note about
such examples soon ...

I think the jury is still out as to whether `inheritance' really does
contribute to good program organisation, reuse, extensibility etc.  These
are certainly apsects that we emphasise (and demonstrate) when we teach
occam (and where there is no *explicit* inheritance mechanism).

//}}}
//{{{  per-object threads versus per-activity threads

You mentioned that ComsTime in Java is defined by "per-object threads".
That's true ... it's following the occam example.  But you then say that,
in occam, ComsTime can be defined using "per-activity threads" and/or
using "per-object threads" depending how the PAR-construct is used.

I thinh there is a mis-understanding here.  The components in a PAR-construct
are "per-object threads", regardless of whether they are in-line code (as in
the definition in Program 1 of your paper) or whether they are PROC instances:

//{{{  ComsTime.occ
#USE "cycles.occ"

PROC ComsTime (CHAN OF BYTE keyboard, screen, error)
  CHAN OF INT a, b, c, d:
  PAR
    Prefix (0, b, a)
    Delta (a, c, d)
    Successor (c, b)
    TimeAnalyser (d, keyboard, screen)
:
//}}}

which is still the `fair' comparison of your Program 1 against its Java
equivalent Program 2.  The semantics of the above PROC instances are just the
in-line coding that appears in your Program 1.  The versions are semantically
equivalent ... both describe four "per-object threads".

In Java, to create a thread we have first to abstract it into a named template
(which generates much syntactic overhead) and, then, instance it.

In occam, to create a thread we *can* first abstract it into a named template
(with very little syntactic overhead) and, then, instance it.  But, if it's
a simple low-level thread (e.g. a single communication) or we only need the
one instance, we can just create the thread directly (without constructing
a named template first).  This is a very powerful facility of occam ... but
it's just a syntactic convenience ... we still have "per-object threads"
as the semantics.

//}}}
//{{{  the `MEMORYLESS' Channel

Youe `MEMORYLESS' Channel is a fast implementation of a one-place FIFO
(e.g. your Channel(1) or the occam `identity' process used by `Prefix').
But it's not an occam channel ... honest!  An occam channel forces direct
synchronisation between the writer and reader.  For example, the first
time a writer wwrites to your Channel() object, it always succeeds straight
away ... regardless of whether there is a reader present.

//}}}
//{{{  output guards in ALTs

Your sread/swrite polling methods are interesting.  They raise the prospect
of output guards in the method of implementing ALTs described in your paper.

I need to think some more on this ... such things have always led to tears
in the past (e.g. the early PACT parallel C as reported at OUG-7 in Grenoble!).

//}}}
//{{{  my problem with IllegalThreadStateException

This hasn't gone away ... but I've find another way to solve the problem
for which IllegalThreadStateException might have been a solution.  That
problem was making multiple readers/writers of channels/buffers secure.
I'll post this new solution shortly ... sadly, it's a slow one (8.8 ms
per ComsTime loop compared with 5.5 ms for my previous BUFFER_OF_INT
compared with 1.5 ms for your Channel(n) compared with 0.6 ms for your
Channel()) ... but we may have to pay this price for security in Java?

Of course, the occam3 equivalent would be simpler, as secure and about
1000 time faster ... (:-) ... now, where is that occam3 ?!!

//}}}

Cheers,

Peter.

cc: occam-com