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

Re: Mobile variables

P.H.Welch writes:
> There was a lot of chat about such things back in '94 ... John Burren,
> myself and some others on the old occam3-talk mailing list (occam3-talk
> became occam-com when we gave up waiting on occam3 :-() ...

I missed out on occam3-talk, and joined occam-com late. You probably didn't
your mail boxes filled with junk ;-)

> Enclosed is one message from June '94 (when, like now, I was trying to
> do anything but exam marking!).  Points:
>   1. Your scheme prevents the sending of mobile-EREW (Exclusive-Read-
>      Exclusive-Write) variables out of scope - which is a good thing.
>   2. Mine didn't, although you couldn't actually make use of a received
>      TOKEN if the SHARED variable it was representing was out of scope.
>      But you could send it back again to a process where the SHARED
>      variable was in scope, which could then re-access it.  This opened
>      a tiny security loophole, hinted at but not explained in the enclosed
>      mailing.  There was a fix for this but, in the spirit of Fermat,
>      was omitted for brevity.  The fix was in the implementation of the
>      TOKEN and in the SHARED variable - not in the syntax or semantics.
>      Sorry, still no time to explain!
>   3. In your produce/consume example, shouldn't the "[2]"s in the parameter
>      lists be omitted?  When defining the network, shoudn't "consume(up,down)"
>      be "consume(down,up)"?

As I said before, yes & yes. The only channels in my previous version were
up and down, and I forgot to check the wiring when I introduced ins and outs.
No doubt there are more like that...

>   4. Your scheme hides the explicit TOKENs of my suggestion :-) ...

I am biased, of course, but I did find your producer/consumer example harder to

Can your SHARED variables also obey standard CREW usage rules?
You seem to rule that out in your email to John.
My variables are not really special. The MOBILE/SHARED qualifier is only a 
convenience for the compiler. What matters is whether they are ever CLAIMed 
when they come under the EREW usage rule. But otherwise they are under CREW. 
As I said in the original note, you might otherwise need to copy a massive 
image across from an ordinary variable into a special EREW variable before 
playing ping pong.

Interesting that our schemes have so much in common. Of course that may be
down to my subconscious remembering your prior work.

Are there any disadvantages of my approach compared with yours?

What needs fixing?

A E Lawrence, MA., DPhil.  	adrian.lawrence@xxxxxxxxxxxxxx
MicroProcessor Unit, 13, Banbury Road, Oxford. OX2 6NN. UK.                
Voice: (+44)-1865-273274,  Fax: (+44)-1865-273275