Message passing concurrency is concurrency among two or more processes (here, a process is a flow of control; rather than a particular type of kernel object) where there is no shared region between the two processes. Instead they communicate by passing messages (not to be confused with Smalltalk-80 messages, which have little to do with concurrency, but see AlanKayOnMessaging). Note that there are several different types of message-passing semantics (reliable/unreliable; asynchronous/synchronous with rendezvous/RemoteProcedureCall). Contrast with SharedStateConcurrency.
ActorsModel is an example of a message passing concurrency model, with reliable messages and supporting both asynchronous and synchronous calls.
MessagePassingConcurrency has the following advantages:
... and disadvantages
- Can be slower compared to SharedStateConcurrency.
- GlobalConsensus much more difficult to achieve; may be impossible in an asynchronous system with errors (i.e. much of the real wold).
- While ValueObjects are handled well in the message passing model, ReferenceObjects are not handled well; as such objects typically maintain references to other objects which might be "owned" by a different process.
The above "disadvantages" should be considered strongly disputed:
- If MessagePassingConcurrency is implemented on top of a shared memory, it is essentially as fast as SharedStateConcurrency. For example, Mach [MachMicrokernel] uses MessagePassingConcurrency and optimizes communication between nodes which have a common memory area. If, OTOH, communication is via a high-latency link, especially if PromisePipelining is used, MessagePassingConcurrency can often be much faster than using a protocol that assumes a simulation of shared memory over that link.
- Global consensus is difficult to achieve if (and only if) there are communication errors, but failing to model the possibility of errors doesn't make them go away. If communication is reliable in any particular case, then this is a non-issue for that case. If communication is not reliable, then it will be unreliable regardless of which concurrency model is used. However, if the model can cleanly report that a failure has occurred, then we are in a much better position to recover from it (usually by falling back to less ambitious goals) than if the model assumed reliability.
Hmm.. Global consensus is impossible whether communication is reliable or not. It depends on whether the upper bound on communication delays is considered known (synchronous) or unknown (asynchronous).
- There are several quite realistic models of asynchronous systems in which global consensus is possible -- see the following papers:
http://csdl2.computer.org/persagen/DLAbsToc.jsp?resourcePath=/dl/proceedings/&toc=comp/proceedings/icdcs/2005/2331/00/2331toc.xml&DOI=10.1109/ICDCS.2005.57
In the latter case, if processes can crash, global consensus is impossible (if termination guarantees must be deterministic).
- In real-world systems, processes can crash and then recover, which can be modelled as a communication failure. So this only prevents consensus from being achieved in protocol runs where processes crash infinitely often, or for catastrophic failures that cannot be recovered from. The important point is, it is not a distinction between synchronous and asynchronous (message passing) systems. In the situations where consensus is possible, it is possible for both sync and async systems, and when it is impossible, it is impossible for both sync and async systems.
Some languages allow only MessagePassingConcurrency. ErlangLanguage is based on a model similar to ActorsModel; OccamLanguage is based on CommunicatingSequentialProcesses. These don't allow shared state as such, but both allow ports (actor names, references) to be passed in messages, which means that two different actors (processes, objects) can share a port to the same third actor.
See also ConceptsTechniquesAndModelsOfComputerProgramming.
CategoryConcurrency
Message Passing Concurrency