Subject: Re: "Message Capsule" Proposal (long)

From: [email-masked] (Leslie Hart)
Date: Tue, 19 Jan 93 10:30:15 MST

> From: Charles Simmons <[email-masked]>
> To: [email-masked], [email-masked], [email-masked]
> Subject: Re: "Message Capsule" Proposal (long)
> 
> As feedback...
> 
> The message capsule proposal might be a bit high level.  E.g. it
> seems to implement the topmost layer of the ISO 7-layer communications
> model which deals with transmitting data between processes running
> on heterogeneous machines.

I'm not familiar with with the ISO 7-layer approach, but what we were 
proposing was a place for each local process (or thread) to store information
about one or more messages.  Other words for capsule might be "handle" or
"envelop".

> 
> "
> 6.1  Advantages
> 
>   - The number of separate send and receive routines is greatly reduced 
>     without sacrificing functionality.  
>   - A user who is used to "common practice" can use the simplified 
>     versions of the routines.  
>   - A user who wants more flexibility only needs to learn about the features 
>     required for his/her specific application.  (For example, if I only need 
>     contiguous messages, then I don't need to know anything about strided data 
>     items.  If the receiving process always knows the data description of 
>     received messages, then I don't need to know about the probe and "info" 
>     routines.)  
>   - "Hidden states" are removed so multi-threaded applications won't get 
>     confused.  
>   - Encapsulation of features in message capsules allows new features to be 
>     added later without modifying syntax of existing routines.  A new feature 
>     would require addition of one or more new routines to modify and examine 
>     message capsules.  
> "
> 
> While the number of separate send and receive routines is reduced,
> the number of other routines are correspondingly increased (e.g. attach
> and info routines).

The increase in routines is not combinatorial, but rather additive.  For 
three new modes each of which have two possible settings, there is a 
maximum of six (6) new routines (ok, maybe 12 if there are other inquiry
functions).  In another approach the number of routines would be *mulitplied* 
by two for each new mode (i.e. multiplied by 8).

> 
> Even in the MPI approach, users can limit themselves to simple versions
> of various rotuines.

Agreed, but I don't think the document has been taken to heart as a 
syntactical or semantical starting point.

> 
> I don't see how capsules keep multi-threaded applications from
> getting confused.  If you have two threads in a receiver that are
> each waiting for messages that look pretty much the same to the OS
> or compiler or library code, it would appear to be fairly easy to
> give the messages to the wrong threads.  The sender really needs
> to attach a thread identifier to a message under certain circumstances.
> 

This responds to some issues that hidden state cause with multithreading.
Such as what does the last message mean?  We don't claim that it deals with
which thread should be a target in a send.  It just removes confusion if you
probe and then wish to receive the message that you probed about.

> 
> [There was a brief thought I had that this proposal reminded me of...
> For certain types of applications, it would be possible for the sender
> to know the layout of data in a receiver's address space.  In an RPC
> application, the receiver could transmit a description of the layout
> to the sender.  In an SPMD application, the sender might just know without
> being told.  This would allow the sender to prepend the layout description
> to her message, and would allow the receiving OS to splatter received data
> directly into user address space.]
> 
> G'luck, Chuck

Thanks for your input, we wanted to start a discussion about these issues.
(BTW, your response was directly to us, so we included it in its entirety to
mpi-comm).

Leslie Hart           Tom Henderson           Bernardo Rodriguez
[email-masked]     [email-masked]     [email-masked]