RE: Loosing abstraction due to non-alting channels

["Gerald H. Hilderink" <g.h.hilderink@xxxxxxxxxxxxx>]

> -----Original Message-----
> From: owner-java-threads@xxxxxxxxx
> [mailto:owner-java-threads@xxxxxxxxx]On Behalf Of M_Boosten
> Sent: Friday, February 18, 2000 10:26 AM
> To: java-threads@xxxxxxxxx; occam-com@xxxxxxxxx
> Subject: Loosing abstraction due to non-alting channels
>
>
> Hi everyone,
>
> Consider two CSP processes:
>
> Process A(in a) {
>   while (TRUE) {
>     a?x;
>   }
> }
>
> Process B(in a) {
>   while (TRUE) {
>     ALT
>       a -> a?x;
>   }
> }
>
> Both these processes have "a*" as _pattern_. I think in CSP
> terms: A == B.
>
> However, JCSP contains channels on which ALTing is not allowed.
> Process A can be connected to such channel.  Whereas process
> B cannot be connected to such channel.  So, in JCSP: A != B.

Although I would not easily write code such as process B, because process A
is more efficient than B, but your point is interesting. The design-freedom
you get with CSP is restricted in JCSP (of course, for good reasons). CTJ
follows the CSP paradigm closely and largely inherits the design-freedom of
CSP. Thus, your example can be build with CTJ (one-on-one) with A == B.
BUT BUT BUT. Unsafe design patterns in CSP will result in unsafe design
patterns in CTJ and the other way around. JCSP tries to eliminate unsafe
design patterns by restricting the language/model to prevent one of building
unsafe design patterns. I belief this is a good approach, but it can be
recognized that there are differences of opinion in the world, e.g.,
C++/Java versus occam.

>
> In JCSP details about the implementation of the process
> need to be known to use processes: some degree of abstraction
> and composability is lost.

Not entirely. By specifying *2OneChannel in the constructors of processes A
and B, information about the implementation is given at the input/output
interface of the processes, i.e., *2OneChannel specifies that process A and
B each provide one reader. One does not need to know about the detailed
implementation of A or B.

With our (CTJ) Channel_of_Xxxx channel (i.e., *2*Channel in JCSP) one cannot
immediately derive the usage of the channel (i.e., alting input or
single/multiple readers), but instead we describe the usage of the channel
in the class description -- the input/output interface is already related to
the task description of the class.

I am worried about the following. Java is an object-oriented programming
language and one advantage of object-orientation is that it can help us to
reuse code (classes). I use this all the time. A problem with distinct
*2*Channel specifications at the input/output interfaces of reusable classes
is that these input/output interfaces can easily conflict with each other
(i.e., channel input/output interfaces do no match) that makes reusing code
(without modifying the code) impossible. For example, in Marcel's example
above One2OneChannel and Any2OneChannel channels are both valid channels,
but once One2OneChannel is declared at the input/output interface of process
A or B then these processes cannot be reused in an Any2OneChannel scenario,
or am I wrong about this? I don't know if the class/interface hierarchy of
the JCSP channels take this into account, but in CTJ these things are more
relaxed.

Cheers,

- Gerald