2

How, if at all, is Message Passing Interface (MPI) related to the general concept of "message passing"?


Admittedly, the question does sound ridiculous. Surely, "Message Passing Interface" is an interface for message passing, right? Nonetheless, it's not actually clear to me if MPI is somehow related to the general concept of message passing in programming languages or if the name "Message Passing Interface" is a historical artifact.

As described by Wikipedia, and as I'm familiar with it, message passing is a concept from object oriented programming in which objects are sent "messages" that request an action but are not tightly coupled to the code implementing that action. The details vary a lot between programming languages but the crucial element that there is a layer of indirection allowing objects to decide how to implement a member functions at runtime and without the caller knowing the details. For example, messages could be a string specifying the requested action along with appropriate arguments and objects receiving a message would decide what code to dispatch to based on the string and arguments. Another component is usually that the message is self-contained and arguments in the message are not references to data outside the message. The caller may have to copy data but the called object is free to modify received data as needed without concern for affecting the caller.

In contrast, MPI is relatively low-level -- being only slightly higher level than BSD sockets by abstracting away OS details -- and is not OOP in nature.

3

message passing is a concept from object oriented programming

No, message passing is a concept in object-oriented programming, not from object-oriented programming.

The term message passing has a general meaning outside of OOP, and in fact outside of programming in general. Alan Kay didn't invent the term message passing specifically for OOP, he simply used the already existing term because it fits perfectly.

OOP has many similarities with the Internet: objects are little machines (interpreters) that have their own private RAM (instance variables) and code (methods) and can only communicate with each other by sending messages. Just like on the Internet, you cannot access another machine's RAM directly, you cannot access another machine's code directly. The only thing you can observe is the response to your message, but you have no idea how that response came into being: it could be a pre-canned response (instance variable), a constructed response (method invocation), the object might have asked someone else to craft the response (delegation / proxying), and so on.

This is no accident: while the Internet and even its predecessor (ARPANet) didn't yet exist back then, Alan Kay knew the people involved and knew their research, and their ideas. Plus, another group at Xerox PARC was just in the process of inventing the Ethernet and personal networking.

And if you think about it, that's also exactly how messages between humans work in the real world. So, it's exactly the other way around from your assumption: the term exists in the real world, it was then used in networking, because it fits the metaphor, and was then used in OOP for the same reason.

Note that, as explained in Doc Brown's answer, MPI in fact works pretty much exactly as you describe for the OOP case, which in turn makes MPI OO.

  • Thanks, the historical context is useful. In the most general case then, should message passing conservatively be understand as sending data (without reliance on shared memory) between independent entities (of some sort)? If it's more subtle, can you recommend a resource that describes message passing outside of OOP? (The wiki article mostly assumes OOP.) – Praxeolitic Oct 5 '16 at 8:02
4

message passing is a concept from object oriented programming

No, message passing is not a concept from object oriented programming, and the Wikipedia article does not state this. Instead, the definition is

message passing sends a message to a process (which may be an [...] object) and relies on the process and the supporting infrastructure to select and invoke the actual code to run. Message passing differs from conventional programming where a process, subroutine, or function is directly invoked by name.

(OOP, or at least certain forms of OOP, make use of this concept, but that does not make MP a concept based on OOP, only vice versa).

MPI provides means to do exactly what the above definition says: for example, a send operation (see here) sends a message to another process (which runs in parallel), with not specifing the name of the called function or the exact code to run. The receiving process has to call MPI_Recv to get the message, so the exact code which gets the message is determined by the receiver, not by the caller.

So in short, the name is not just a "historical artifact", quite the opposite, the name fits well.

  • After the first paragraph the wiki article describes message passing in terms of objects without qualification ("in this case", "sometimes", etc). It also draws an analogy with function calls which are very unlike the semantics of MPI_Send (no arguments, no return, just a stream of bytes). – Praxeolitic Oct 5 '16 at 6:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.