Java Threads Workshop - Discussion Group 1 Minutes

Date: Wed, 25 Sep 1996 10:49:14 +0100
From: Richard Beton rdb@roke.co.uk
Organization: Roke Manor Research Ltd
To: occam-com@ukc.ac.uk
Subject: Java Threads Workshop - Discussion Group Minutes
Content-Type: text/plain; charset="us-ascii"
Status: RO

As promised, here are the notes I took from the Discussion Group yesterday, at the Java Threads Workshop.

(For those not able to attend, this was one of two such groups, so I'm only reporting herein half of the discussion held).

The following topics were discussed:

• untyping of Gerald's Java channels - Chan of Object?
• the mechanism by which a Protocol is sent across channels
• the use of recycling to reduce g.c. overheads.
• problems of synchronising the recycler between threads - it holds global knowledge of protocol allocation
• cloning objects would be the occam-like alternative to reference passing, and would be compatible with hardware links.
• the need for a deeper CSP analysis of Gerald's channels to get a higher confidence in their behaviour.
• disussion of output guards - how and why Gerald might eliminate them.
• issues of hardware links between processors
• modelling a channel class hierarchy on the transputer implementation so that Channel provides an abstraction which is supported both by local memory communication and also by hardware links, TCP/IP, etc. There was not much support for Gerald's existing Link class proposals.
• use of OO 'factories' to return new concrete implementations of Channels according to rules specifying whether each Channel is local or link-based.
• Passing channels along channels may result in loss of program provability.
• Cloning of data across channels (rather than passing references) may be necessary to ensure scalability of algorithms.

As you can see, we raised a lot of questions, and found few answers, but overall, poor Gerald had a Hard Time!

IMHO, Gerald is doing good work with his communication library, but I have reservations that some of the decisions he has made are at odds with the familiar ways of the transputer. These decisions need careful justification, because David May et al had to consider similar issues, and actually did a jolly good job designing transputer channels and links, which we ignore at our possible loss. It's not that a channel library should emulate occam just for the sake of it, but rather that it should emulate the tried and tested ideas behind occam, unless there is a sound reason not to.

Rick

-- 
              Richard Beton BSc MInstP CPhys
      Roke Manor Research, Romsey, Hampshire SO51 0ZN
-------  Standard disclaimer about my own views etc  -------
           See http://www1.roke.co.uk/WHR/WHR.html