Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!samsung!think.com!yale!quasi-eli!cs.yale.edu!ghostwheel.eng.yale.edu!llw
From: llw@ghostwheel.eng.yale.edu (Louis L. Whitcomb)
Newsgroups: comp.sys.transputer
Subject: Re: Anarchic protocol ANY (occam2)
Message-ID: <LLW.91May17095750@corwin.eng.yale.edu>
Date: 17 May 91 09:57:50 GMT
References: <9105152020.AA15174@theory.TN.CORNELL.EDU>
Sender: news@cs.yale.edu (Usenet News)
Organization: Yale University, Center for Systems Sciences
Lines: 61
In-Reply-To: COS99284@UFRJ.BITNET's message of 15 May 91 21: 04:29 GMT
Nntp-Posting-Host: corwin.eng.yale.edu


In article <9105152020.AA15174@theory.TN.CORNELL.EDU> COS99284@UFRJ.BITNET (Luiz Felipe Perrone) writes:

>   Dear netters,
>
>     I have tried to use channels of protocol ANY in a very particular
>   situation and my results were very strange...


Greetings:

  The behavior of software and hardware channel communication in
in the Inmos OCCAM2 compiler is not identical.

  Here's why: In all channel transactions, each argument of an "!"  and
"?"  statement is an individual transaction.  The number and length of
the arguments in both the ? and ! must be absolutely *identical* on
both the sending and receiving end.  In your example the seven !
arguments are received by four ? arguments of differing length.
You'll find that the ! has completed, the first four ? arguments have
taken the value of the first four ! arguments, and that the ? is
waiting (forever) for its fifth argument.

  Curiously, you'll find that your code sample will run fine in a
configuration where the channel "to.p2" is a hard link, but not when
it is a soft link. Try it.  The implementation of channel
communication in OCCAM2 behaves differently on hard and soft channels.

  The simplest example of this behavior I know of is the following
buffer process which looks to be a universal, protocol-independent
buffer:

PROC byte.buffer( CHAN OF ANY in, out )

  BYTE data :

  WHILE TRUE
    SEQ
      in  ? data
      out ! data
:

Which works fine over hard channels, but will work on soft channels if
and only if the sending and receiving processes are actually sending
and receiving *individual* bytes.

The moral of the story: If you use OCCAM2, use explicit protocols -
even though they are cumbersome and restrictive.  It is hard to track
down bugs without them.

Note that ihe implementation of channel communication in the newly
released INMOS ANSI C compiler does *not* suffer from this curious
design flaw.

  The Best,

      -Louis.
--
Louis L. Whitcomb              llw@corwin.eng.yale.edu    ph: (203) 432-4237  
Yale Robotics Laboratory                                  fx: (203) 432-7481 
Department of Electrical Engineering, 1968 Yale Station, New Haven, CT 06520