Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!usc!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!emory!hubcap!Steven
From: zenith@ensmp.fr (Steven Ericsson Zenith)
Newsgroups: comp.parallel
Subject: [NAGKVF@vax.oxford.ac.uk: Original producer-consumer question]
Message-ID: <12942@hubcap.clemson.edu>
Date: 6 Feb 91 14:35:07 GMT
Sender: fpst@hubcap.clemson.edu
Lines: 57
Approved: parallel@hubcap.clemson.edu

Vince Fernando was kind enough to forward the original question, which I
discussed in previous mail. I think it raises some interesting points.
Taken in the full context the part quoted by Phillip Hallam-Baker (and
which I interpreted) makes more sense.

My answer to Vince's question remains essentially the same except, in
light of the more detailed explination, I think it is important to
consider Harry Jordan's points and the implications there of.

Steven.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
From: "Vince Fernando"@nsfnet-relay.ac.uk

The following was extracted from the article:
Jaap Hollenberg
"People are getting more comfortable with parallelism" - an interview
with Harry Jordan
Supercomputer (P O Box 4613, 1009 AP Amsterdam, The Netherlands), 
vol. 40, November 1980, pages 8-12 
....
 Languages
 How about parallel languages, could Fortran be parallel ?
 ....
 The major difference between something like occam and parallel Fortran is the
 distinction I try to draw between the communication of the information from
 a process which produces it to one that consumes it by either producer-
 or consumer-initiated transmission paradigm, that is the producer is 
 responsible for sending information, specifically to the processor that
 will use it. So the binding must be done in such a way that the producer can
 predict the receiver well enough in advance, that the program will scale
 effectively, that means there must be a large amount of buffering because 
 otherwise if you scale up the size the amount of this buffer time is
 reduced and eventually the communication dominates the whole system. In the
 parallel Fortran area (anybody's standard, IBM, PCF) it is a receiver-initiated
 transmission.You can assume that the data is somehow left behind by name by the
 producers (we typically associate that with a storage cell in a shared-memory)
 and the consumer then names the data and retrieves it under its own-initiative.
 To me the two programming paradigms are very different. One of them leaves the
 management of latency to the user. The user spends a good deal of time trying
 to map data so that very little communication takes place; he tries to arrange
 the sends and the receiver so that the send takes place well ahead of the
 receive so that there is no waiting. There is a tremendous amount of 
 management function placed on him. In the parallel Fortran paradigm the user
 has very little management requirement, he can write an algorithm that - apart
 from the fact that he must use the number of processors - works very much like
 the programming paradigm he is used to.  ... 

Does anybody have any comments regarding this article ? Particularly, can we say
that occam is a producer-initiated language  and Fortran is a 
consumer-initiated language ?


Vince Fernando
NAG
Jordan Hill, Oxford OX2, UK
Eamil: nagkvf@uk.ac.oxford.vax
       na.fernando@na-net.ornl.gov