Posts Tagged ‘concurrency’

Introduction to Erlang : Message Passing

This entry is part 15 of 16 in the series Introduction to Erlang

Message Passing

The communication model (among processes) in Erlang is message passing. No much need to be said about this. Erlang processes share no memory. The way that processes communicate is via (asynchronous) message passing. Every process (even the shell) holds a mailbox queue where incoming messages are placed until received by the process. Message passing is asynchronous because the sending process does not block on send. On the other hand, receiving a message in Erlang is a blocking operation.


In this subsection I will describe some of the characteristics of message passing in Erlang.


As I already mentioned, message passing in Erlang is a non-blocking operation.

Data Copy

The message’s data are copied from the sending process to the receiver’s message queue, so the receiver gets a fresh copy of the data.


Erlang runtime guarantees that if two messages are sent from node A to node B and both are delivered, then the ordering of these messages is kept (causal ordering).

Successful Send

The send operation always succeeds (even if the target is a non-existing process) and evaluates to the data sent. An exception is when trying to send data to a non-existing registered process.
Read the rest of this entry »

Introduction to Erlang : Concurrency (Processes)

This entry is part 14 of 16 in the series Introduction to Erlang


Concurrency is defined as “the temporal property of two things happening at the same time” (according to WordNet). In Computer Science, the definition is “concurrency is a property of systems in which several computations are executing simultaneously, and potentially interacting with each other. The computations may be executing on multiple cores in the same chip, preemptively time-shared threads on the same processor, or executed on physically separated processors.” (according to Wikipedia).

In practise, if two, or more, tasks are concurrent, then they can run in parallel. This implies that there are no data dependencies among them. For example, the following tasks

  • unlock the car (the car was locked)
  • start the engine of the car (the engine was off)
  • drive the car

are non-concurrent since they have dependencies. One cannot start the engine of the car without first entering the car and she cannot drive it without first starting the engine. These tasks have to be executed sequentially (with a predefined order) no matter if more than one person (processing unit) help. On the other hand

  • doing the laundry
  • washing the dishes
  • go for shopping

can be potentially run in parallel. For example, three different family members can handle one task each. Moreover, if only one person has to do all the tasks, she can decide to perform them in any order she decides since there are no dependencies among them.
Read the rest of this entry »