[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CHAN variants

B.M. Cook writes:

> Is it ... a sender to several receivers, synchronized so that all must have
> received the message before the transaction completes and the sender
> continues?  [And, if it's a hardware bus this is easily achieved.]

Not quite. A sender to several receivers, but the communication is an atomic
action: the event is simultaneous.

Indeed, as I have already mentioned in our private conversations, I am
introducing a new SYNC constructor to "merge" events. This is intimately
related to the COMMON chan (I think that *COMMON* is the answer to my
original question), as well as to some of the ideas that we discussed last
year (ASS, or MASS assignment).

What is not yet clear in "ocham" and "HCSP" is what should be taken as
primitive, although SYNC is a very strong candidate as one such. I won't
say more about that until I have explored all the implications further.

> If so, isn't this a multicast operation?

A *synchronised* multicast, perhaps.

> How about keeping occam channel identifier declarations as they are but
> allowing multiple, parallel output ...
> CHAN OF XXX a, b:
>   XXX x:
>   SEQ
>     a ? x
>     -- etc.
>   XXX y:
>   SEQ
>     b ? y
>     -- etc.
>   SEQ
>     a,b ! value      -- I suppose this is equivalent to
>     -- etc.          -- PAR
>                      --   a ! value
>                      --   b ! value

[N] CHAN OF blah common :
PAR i = 1 FOR N-1
  common[i] ! v  
  common[i] ? x[i]

  (N - 1)
  || ((common[i] ! v -> Q ) || (common[i] ? x   -> P  ))
   0                    i                          i

doesn't quite work because the events constituting channels are usually taken
as disjoint. The process above engages in N separate events rather than a 
single event. (There are other *far stronger* reasons for introducing
merged events: since that notion is present anyway, it is the natural to
use it to describe "COMMON" channels.)

Replace PAR by SYNC above, and we may have a law of ocham/HCSP.

Simple tentative examples of the sort of thing that I am wondering about here

COMMON CHAN OF bits common:
  common ! v
  common ? x
  common ? y

Note that writing

COMMON CHAN OF ECL common:            might not be wrong if we had a
SYNC                                  "wired-OR" ECL signal. Actually, I
  common ! v1                         think that this should be illegal
  common ! v2                         (aka bus contention if v1 <> v2).
  common ? x                          And the ECL implicit OR gates should
                                      be made explicit....


COMMON CHAN OF blah c:                [2] CHAN OF blah c:
SYNC                                  SYNC
  c ! v                 is equiv to     c[0] ! v
  c ? x                                 c[1] ! v
  c ? y                                 c[0] ? x    
                                        c[1] ? y

I don't think that the RAZOR means that we should use a cumbersome verbose
notation for a simple idea. Of course, in software/hardware codesign,
an "ocham" compiler would make this transformation when it was emitting
"software" rather than "hardware". Of course, ocham may turn out to be 
occam2.83215? :-)

All this is tentative: "HCSP" and "ocham" is still evolving. I don't want to 
say too much about it in public yet until I am convinced that it all hangs
together, is self consistent, and doesn't lead into any black holes. In
particular, HCSP has to be rather radical in its denotational semantics, and
I have to convince myself that it works properly... 


PS. Any advance on COMMON ? Jeremy Martin suggested MULTI. Any more from the
    rest of you occamists, and have you all been subverted into Javaists? 

Adrian Lawrence.
adrian.lawrence@xxxxxxxxxxxxxx or adrian.lawrence@xxxxxxxxxxxxxxx
  MicroProcessor Unit        | Computing Laboratory,
  13, Banbury Road,          | Wolfson Building,
  Oxford. OX2 6NN.           | Parks Road, Oxford.
  UK.                        | OX1 3QD. UK.
Voice: (+44)-1865-273274,(+44)-1865-283526  Fax: (+44)-1865-273275