node71.html

Design and building parallel program

three outports, and each consumer has a single inport.  Three mergers
connect the outports with the inports.</em><A NAME=figfmmany>&#160;</A><BR>
<P>
<P>
A many-to-many communication structure allows multiple senders to
<A NAME=9140>&#160;</A>
communicate with multiple receivers.  This structure is just a
<A NAME=9141>&#160;</A>
generalization of the many-to-one structure and can be implemented in
a similar fashion, by using multiple mergers.  The following code
fragment implements a typical many-to-many structure.  As illustrated
in Figure <A HREF="node71.html#figfmmany" tppabs="http://www.dit.hcmut.edu.vn/books/system/par_anl/node71.html#figfmmany">6.4</A>, this code uses three mergers to connect
four producer processes with three consumers.  Each producer has an
array of three outports; messages sent on outport <em> i</em>
 are routed
to consumer <em> i</em>
.  Each consumer has a single inport.
<P>

<PRE><TT> aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa&#175; \
		<tt> OUTPORT(integer) pos(3,4)</tt>  						 ! <IMG BORDER=0 ALIGN=MIDDLE ALT="" SRC="img890.gif" tppabs="http://www.dit.hcmut.edu.vn/books/system/par_anl/img890.gif"> outports
<P>
		<tt> INPORT (integer) pis(4)</tt>    						 ! 3 inports
<P>
		<tt> do i=1,3</tt>                   						 ! 3 mergers
<P>
				<tt> MERGER(in=pis(i),out=pos(i,:))</tt>  				 !
<P>
		<tt> enddo</tt>                      						 !
<P>
		<tt> PROCESSES</tt>                  						 !
<P>
				<tt> PROCESSDO i=1,4</tt>            				 !
<P>
						<tt> PROCESSCALL producer(pos(1,i))</tt> 		 ! 4 producers
<P>
				<tt> ENDPROCESSDO</tt>              				 !
<P>
				<tt> PROCESSDO i=1,3</tt>           				 !
<P>
						<tt> PROCESSCALL consumers(pis(i))</tt> 		 ! 3 consumers
<P>
				<tt> ENDPROCESSDO</tt>              				 !
<P>
		<tt> ENDPROCESSES</tt>              						 !
<P>
</TT></PRE>

<P>
<H2><A NAME=SECTION03343000000000000000>6.4.3 Dynamic Channel Structures</A></H2>
<P>
<A NAME=9161>&#160;</A>
Port variables can be incorporated in messages, hence transferring the
<A NAME=9162>&#160;</A>
ability to send or receive on a channel from one process to another.
A port that is to be used to communicate port values must have an
appropriate type.  For example, the following declaration specifies
that inport <tt> pi</tt> will be used to receive integer outports.
<P>
<tt> INPORT (OUTPORT (integer)) pi</tt>
<P>
A receive statement applied to this port must specify as an argument
an integer outport variable into which the incoming port is to be
placed.  For example, the following code fragment first declares an
integer outport variable <tt> qo</tt> and then receives an outport of the
same type into that variable.
<P>

<PRE><TT> aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa&#175; \
		<tt> INPORT (OUTPORT (integer)) pi</tt> 						 ! Inport
<P>
		<tt> OUTPORT (integer) qo</tt>          						 ! Outport
<P>
		<tt> RECEIVE(pi) qo</tt>                						 ! Receive outport
<P>
</TT></PRE>

<P>
<P><A NAME=10276>&#160;</A><IMG BORDER=0 ALIGN=BOTTOM ALT="" SRC="img891.gif" tppabs="http://www.dit.hcmut.edu.vn/books/system/par_anl/img891.gif">
<BR><STRONG>Figure 6.5:</STRONG> <em> Dynamic channel creation in the bridge construction problem.
In (a), the <tt> bridge</tt> process creates a new channel.  In (b), the
new channel's outport is communicated to the <tt> foundry</tt> process.
In (c), the new channel is used to return a datum (<tt> girder</tt>) to
<tt> bridge</tt>.  In (d), the communication is
complete.</em><A NAME=figfmback>&#160;</A><BR>
<P>
<P>
Program <A HREF="node71.html#progfmd" tppabs="http://www.dit.hcmut.edu.vn/books/system/par_anl/node71.html#progfmd">6.6</A> illustrates the transfer of ports in messages.
<A NAME=9181>&#160;</A>
This program implements a variant of the bridge construction
<A NAME=9182>&#160;</A>
program (Program <A HREF="node68.html#progfmbuild" tppabs="http://www.dit.hcmut.edu.vn/books/system/par_anl/node68.html#progfmbuild">6.1</A>) in which the <tt> bridge</tt>
process makes explicit requests for data from the <tt> foundry</tt>
process.  Recall that in the original program, a stream of girders was
communicated on a channel connecting <tt> foundry</tt> to <tt> bridge</tt>.
In Program <A HREF="node71.html#progfmd" tppabs="http://www.dit.hcmut.edu.vn/books/system/par_anl/node71.html#progfmd">6.6</A>, things are reversed.  A stream of requests
is communicated on a channel connecting <tt> bridge</tt> to <tt> foundry</tt>.
Each request comprises an outport that <tt> foundry</tt> uses to return a
single data value to <tt> bridge</tt>.  Hence, when <tt> bridge</tt> requires
data, it creates a new channel, sends the outport to <tt> foundry</tt>,
and waits for a reply on the inport (Figure <A HREF="node71.html#figfmback" tppabs="http://www.dit.hcmut.edu.vn/books/system/par_anl/node71.html#figfmback">6.5</A>).  This
<A NAME=9196>&#160;</A>
implements a <em> synchronous
 </em> communication protocol: the
<A NAME=9198>&#160;</A>
producer (<tt> foundry</tt>) produces data at the rate specified by the
consumer (<tt> bridge</tt>) and hence cannot ``run ahead'' of the consumer.
<P>
<P><A NAME=progfmd>&#160;</A><IMG BORDER=0 ALIGN=BOTTOM ALT="" SRC="img892.gif" tppabs="http://www.dit.hcmut.edu.vn/books/system/par_anl/img892.gif"><P>
<P>
<A NAME=9237>&#160;</A>
In this example, it would perhaps be simpler to specify the desired
behavior by using static ``request'' and ``data'' channels.  With this
<A NAME=9238>&#160;</A>
structure, the producer sends a datum on the data channel each time it
receives a request on the request channel.  However, dynamic channels
can be useful in more complex communication structures where a request
must be routed through several intermediate steps before being
serviced.
<P>

<BR> <HR><a href="msgs0.htm#2" tppabs="http://www.dit.hcmut.edu.vn/books/system/par_anl/tppmsgs/msgs0.htm#2"><img ALIGN=MIDDLE src="asm_color_tiny.gif" tppabs="http://www.dit.hcmut.edu.vn/books/system/par_anl/asm_color_tiny.gif" alt="[DBPP]"></a>    <A NAME=tex2html2799 HREF="node70.html" tppabs="http://www.dit.hcmut.edu.vn/books/system/par_anl/node70.html"><IMG ALIGN=MIDDLE ALT="previous" SRC="previous_motif.gif" tppabs="http://www.dit.hcmut.edu.vn/books/system/par_anl/previous_motif.gif"></A> <A NAME=tex2html2807 HREF="node72.html" tppabs="http://www.dit.hcmut.edu.vn/books/system/par_anl/node72.html"><IMG ALIGN=MIDDLE ALT="next" SRC="next_motif.gif" tppabs="http://www.dit.hcmut.edu.vn/books/system/par_anl/next_motif.gif"></A> <A NAME=tex2html2805 HREF="node67.html" tppabs="http://www.dit.hcmut.edu.vn/books/system/par_anl/node67.html"><IMG ALIGN=MIDDLE ALT="up" SRC="up_motif.gif" tppabs="http://www.dit.hcmut.edu.vn/books/system/par_anl/up_motif.gif"></A> <A NAME=tex2html2809 HREF="node1.html" tppabs="http://www.dit.hcmut.edu.vn/books/system/par_anl/node1.html"><IMG ALIGN=MIDDLE ALT="contents" SRC="contents_motif.gif" tppabs="http://www.dit.hcmut.edu.vn/books/system/par_anl/contents_motif.gif"></A> <A NAME=tex2html2810 HREF="node133.html" tppabs="http://www.dit.hcmut.edu.vn/books/system/par_anl/node133.html"><IMG ALIGN=MIDDLE ALT="index" SRC="index_motif.gif" tppabs="http://www.dit.hcmut.edu.vn/books/system/par_anl/index_motif.gif"></A> <a href="msgs0.htm#3" tppabs="http://www.dit.hcmut.edu.vn/books/system/par_anl/tppmsgs/msgs0.htm#3"><img ALIGN=MIDDLE src="search_motif.gif" tppabs="http://www.dit.hcmut.edu.vn/books/system/par_anl/search_motif.gif" alt="[Search]"></a>   <BR>
<B> Next:</B> <A NAME=tex2html2808 HREF="node72.html" tppabs="http://www.dit.hcmut.edu.vn/books/system/par_anl/node72.html">6.5 Asynchronous Communication</A>
<B>Up:</B> <A NAME=tex2html2806 HREF="node67.html" tppabs="http://www.dit.hcmut.edu.vn/books/system/par_anl/node67.html">6 Fortran M</A>
<B> Previous:</B> <A NAME=tex2html2800 HREF="node70.html" tppabs="http://www.dit.hcmut.edu.vn/books/system/par_anl/node70.html">6.3 Communication</A>
<BR><HR><P>
<P><ADDRESS>
<I>&#169 Copyright 1995 by <A href="msgs0.htm#6" tppabs="http://www.dit.hcmut.edu.vn/books/system/par_anl/tppmsgs/msgs0.htm#6">Ian Foster</a></I>
</ADDRESS>
</BODY>