Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!know!sdd.hp.com!wuarchive!emory!hubcap!ciancarini-paolo
From: ciancarini-paolo@CS.YALE.EDU (paolo ciancarini)
Newsgroups: comp.parallel
Subject: Re: parallel programming model
Message-ID: <12252@hubcap.clemson.edu>
Date: 13 Dec 90 21:02:22 GMT
Sender: fpst@hubcap.clemson.edu
Organization: Yale University Computer Science Dept., New Haven, CT 06520-2158
Lines: 127
Approved: parallel@hubcap.clemson.edu


In article <12242@hubcap.clemson.edu> zenith@ensmp.fr (Steven Ericsson-Zenith) writes:
>
   (answering this statement of mine:)
>   More seriously, I would say that Linda'a Generative communication
>   through a Tuple Space is different from both.
>
>I can't agree with you here Paolo. In the Linda model processes interact
>via the global associative memory of Tuple Space. In a shared memory
>model processes interact via an addressable global space. 

When a discussion starts, is always useful to define terms. I will use your definitions.
A global associative memory is NOT a global addressable memory.
Normally an address is a name denoting a state. And a state
should be something that I can see as a whole in an arbitrary point of time.

Where are addresses in the Tuple Space? 
An associative memory has different properties from an 
addressable memory, especially from the point of view of parallelism;
for instance, how can be you sure that a tuple is NOT contained in the Tuple Space?
Which address are you going to look into?

>In message passing processes interact via shared objects (which in some forms are
>dynamically addressable) called "channels" or "mailboxes" or somesuch.
>The behavioral characteristics may differ but what we have here are
>essentially variants of the same model - the persistent nature of the
>intermediary objects being the significant disinquishing characteristic.
>

So maybe YOU are self-contradictory!
What do you think of the persistent nature of tuples in Linda?
are they messages? Is Linda a msg oriented model?

>It would seem desirable to have all process interactions defined by the
>associated "interaction model". 

Again, we need to define a term: model. I believe that both you and I
are using this word in two meanings,
when speaking of programming paradigms and languages:

1) a model is a concrete implementation of a language (its run-time system);
2) a model is a semantic paradigm, i.e. an abstract framework
and maybe a general formalism to specify abstract machines
(i.e. operational semantics for programming languages)..

I do not know what is the "interaction model" you are speaking about.
I interpret it in the sense of 2). I know only two major
semantic paradigms for parallelism:
interleaving semantics (as given originally by
Milner for CCS) and "truly distributed" semantics (as in Petri Nets).
They seem very different to me, and by the way they can be used
to characterize very different (abstract or concrete) implementations of the same language.
Literature on this argument is growing. If interested,
I can send you a paper by D.Yankelevich and myself
on Linda formal semantics given in terms of Petri Nets, by translation in CCS, 
using the Chemical Abstract Machine, using Plotkin's SOS (this comes in two
flavors: interleaving and truly distributed).

>
>Linda's distinquishing characteristic is "value associative matching",
>which amounts to complex address translation in a global shared memory -

This is an implementation issue, of course, and by the way
in a very different context 
it is a feature of Prolog implementations based on WAM 
(so this is hardly "Linda's distinquishing characteristic").
The Linda global shared memory
could be distributed; its consistency then should be maintained.
I can send you a paper also about this, if interested.

>i (e.g. a decent system of
>batch files with native job control language, and "sockets" is likely to
>do as well - maybe better - than any network distributed version of
>Linda, for as much effort).
>

This is a statement that should be demonstred. My experiences
with sockets and the Unix "job control language" when used
for implementing a distributed runtime system
across a network are quite discouraging.
On the other side, some recent results obtained with Network Linda
are astonishing (if you need more details, please ask). 

>
>Well "agents" "know" about Tuple space and also must "know" about data
>structure and type. This is directly analogous to a "knowledge" of
>communication channels, mail boxes and protocols in message passing.
>

No. (I presume you are again speaking of semantic issues). 
Agents do not know about their Tuple Space. For instance,
they CANNOT consume the entire tuple space - this is simply impossible
in the abstract model. Actually the same concept of
Tuple Space "state" is an empty concept,
because in a truly distributed implementation
you cannot take a snapshot of such a beast.

>
>Again, Tuple Space epitomises a "global environment" and in current
>implementations I've seen at Yale "agents" may indeed share variables ..
>I've already indicated that I view side effecting processes as
>undesirable.
>

I am not aware of the implementations you are speaking about.
In the pure Linda model, that is our argument of discussion,
agents do not share variables. Period.
(I agree that side effects are undesirable; this is not an issue).

>Linda is a variant of a model I have come to call the "interacting
>process model"(nee MIMD), members of this model are distinquished by an
>associated "interaction model" which captures the means by which
>processes "communicate" and "synchronize" (in this sense Occam, Linda
>and indeed Ease are members of the Interacting Process Model).
>

Are you speaking about implementations again,
or about semantic paradigms? 
Any reference to this "interacting process model"?

Can I give semantics to Linda, or Ada, or Occam
using this paradigm? 
Which is its relationship to more established abstract frameworks?


Paolo Ciancarini
Universita' di Pisa (Italy) and Yale University (USA)