Concurrency-Oriented

A term describing a programming language paradigm where independent parts of the problem can be represented as independent computations. This requires that concurrency should be easy, with language support, that to some level concurrency be transparent, and that the implementation should ensure it is cheap.

The two major inspirations for this term are Mozart/Oz, which has declarative concurrency, and Erlang, which has message-passing concurrency (also referred to as the Actor model), but any language marked here as concurrent is similar to one of these two.

The basic properties seem to be (as outlined by Joe Armstrong - see his papers below):

Concurrency-Oriented languages must support processes. A process can be thought of as a self-contained virtual machine.
Several processes operating on the same machine must be strongly isolated. A fault in one process should not adversely affect another process, unless such interaction is explicitly programmed. Two processes operating on the same machine must be as independent as if they ran on physically separated machines.
Each process must be identified by a unique unforgeable identifier.
There should be no shared state between processes. Processes interact by sending messages. If you know the identifier of a process then you can send a message to the process.
Location transparency: you send a message to a process the same way no matter what machine it's on, you don't have to care about locations.
Message passing is assumed to be unreliable with no guarantee of delivery:
- Message passing is atomic: a message is either delivered in its entirety or not at all.
- Message passing between a pair of processes is ordered [If P1 sends X then Y to P2, P2 will receive X before Y].
- Messages should not refer to mutable data. [Reason: if sender crashes or laters data, what happens to message?]
It should be possible for one process to detect failure in another process. We should also know the reason for faiure.

He also outlines some essential requirements:

Concurrency: The computational effort needed to create or destroy a concurrent process should be very small, and there should be no penalty for creating large numbers (explained elsewhere as hundreds of thousands) of concurrent processes.
Error encapsulation: Errors occurring in one process must not be able to damage other processes in the system.
Fault detection: Exceptions should be detectable and handlable both locally, in the process where the exception occurred, and remotely - in a non-local process.
Fault identification: We should be able to identify why an exception occurred.
Code upgrade: There should exist mechanisms to change code as it is executing and without stopping the system.
Persistence: We need to store data in a manner which survives a system crash. More precisely, we need to store selected data in a manner which survives a system crash.

Various papers by Joe Armstrong who developed the idea.
A discussion on it at LtU.

This page is linked from: Actor