Re: Mobile variables

[A E Lawrence <adrian.lawrence@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>]

Lawrence Dickson wrote:
> 
> Richard Beton wrote:
...
> > Lawrence Dickson wrote:
> >
> > > What happens if the variable you are passing around
> > > is a part of a larger array, created by abbreviation?
> > > Then when the process block exits the scope of the
> > > abbreviation, isn't its parent array fragmented?
> > >    Larry

No. You don't move any data at all. Only pointers to it, or to slices
which may have been identified by abbreviation. So fragmentation does
not arise, except perhaps in terms of exclusive ownership.
But my scope rules ensure that the ownership returns to top level at the
end of the block. So even "fragmented ownership" lasts only so long as
the programmer directs, and is automatically eliminated afterwards.

> > > I thought of something like this a couple years ago,
> > > but it seemed it would require an "Independent of
> > > Abbreviation" checking, which would complicate
> > > separately compiled procedures and the like.
> >
> > I'm not quite sure I understand the question, so I'll probably reveal my
> > ignorance, but here goes...
> >
> > One of the key features of occam abbreviations is that they allow a
> > process to alter the contents of a well-defined region of an array
> > without actually fragmenting the original array - the abbreviated part
> > is still a subset of the whole. Therefore, passing array abbreviations
> > as mobile variables would seem like an eminently sensible thing to be
> > doing. 'Mobile' variables are only mobile in the sense that their
> > 'ownership' moves between processes, whilst the data itself remains in
> > the same memory locations, thus avoiding copying operations.

Yes. The altered data will stay at the same location. That's the whole
point of all this stuff. To avoid any redundant moving or copying of
data. I suppose that an insane compiler might be entitled to move to
data for some weird internal reason: maybe it might spot that
realignment on word boundaries might optimize subsequent operations.

> If I remember the notation used right - here is the problem (ch is
> declared way farther back somewhere):

ch can't be declared farther back in my system, for the declaration
CHAN OF VAR x ch:
binds x which must be in scope. So
 
> [3]INT array:
> SEQ
>   INT x IS array[1]:
>   SEQ
>     ch ! VAR x

This would have to be something like
MOBILE [3]INT array:
SEQ
  INT x is array[1] :
-- now x is in scope so we can declare a VAR CHAN to move it
  CHAN OF VAR array ch:
  CLAIM x
    ch ! VAR x
    ch ? VAR x  
Obviously real code will so some other stuff, but this shows that the
receiver must be within the scope of both the channel declaration and of
the abbreviation. At the end of the CLAIM block, the ownership is
returned to the outer level and is no longer EREW.

> Now, when the abbreviation goes out of scope, and array is reassembled
> from its parts, the middle is missing (is in the scope of some parallel
> process outside the declaration of array).

I hope that you can see why this is impossible (?) in my proposal.

Adrian
--
Dr A E Lawrence (from home)