Distributed Life

Concurrency

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.

Concurrency in Erlang

Erlang was built with concurrency and fault-tolerance in mind.

Processes

The granularity of concurrency in Erlang is a process. A process is an activity/task that runs concurrently with and independently from the other processes (though processes can interact with each other using messages, links, etc. as you shall see later). Processes in Erlang are different than the processes and threads most people are familiar with. Erlang processes are lightweight, operate in (memory) isolation from other processes, and are scheduled by the Erlang’s Virtual Machine (VM). The creation time of process is very low, the memory footprint of a just spawned process is very small, and a single Erlang VM can have millions of processes running.

Messaging 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. Sending a message in Erlang is a non-blocking operation that always succeed (more in the next post).

Why Message Passing?

But why message passing? We are so used to the shared memory model, why changing it?

Here are some characteristics that are part of Erlang mostly because of the message passing memory model.

Memory independency

While executing, no shared memory among processes means that there is no chance that a process will cause a memory corruption to another process. The programmer does not have to worry about data races, data corruption, memory synhronization, etc.

Crash independency

Processes do not share anything. As a result, the failure (crash) of a process cannot affect another. This is very helpful when builting fault-tolerant and reliable systems (most of the “real-world” systems). Due to this, Erlang inherits the “let it fail” programming approach; if something “bad” happens, let the process fail and handle the process failure instead.

Distributed programming

Message passing allows for easier distributed programming. Imagine if you want to distribute an application that uses shared memory. To do this, one should either use a message passing solution (such as MPI) or a Distributed Shared Memory system (DSM), that also uses message passing to operate. Why not using message passing in the first place? Especially in Erlang, message passing allows for location transparency (when sending a message there is no difference to the programmer if the receiver resides in the local or a remote node).

Creating Processes

Erlang provides Built-In Functions (BIFs) that are used to spawn new processes. The simplest one is spawn/1|3 (the 1|3 denotes that both spawn/1 and spawn/3 functions exist).

pid Datatype

pid stands for Process identifier and is the datatype used for the unique process identifiers that are assigned to every process.

spawn/1|3

Creates a new process and returns its pid. The new process is placed in the system scheduler queue, so it will be run some time later.

spawn/1

Called as spawn(Fun). The new process will run function Fun with an empty list ([]) as input.

spawn/3

Called as spawn(Module, Function, Args). The new process will run function Module:Function with the elements of the list Args as input.

Examples

print() ->
    io:format("I am process ~w~n", [self()]).
print(I) ->
    io:format("I am process ~w~n", [I]).
 
spawnPrint() ->
    spawn(?MODULE, print, []).
%or spawn(fun print/0).
 
spawnPrintN(0) ->
    done;
spawnPrintN(N) when is_integer(N), N > 0 ->
    spawn(?MODULE, print, [N]),
    spawnPrintN(N - 1).
 
spawnSpawn(0) ->
    io:format("I am a 'lief'!~n"),
    done;
spawnSpawn(N) when is_integer(N), N > 0 ->
    spawn(?MODULE, spawnSpawn, [N - 1]),
    spawnSpawn(N - 1).
 
spawnSlashOneA() ->
    spawn(fun print/0).
 
% spawning an anonynous function
spawnSlashOneB() ->
    spawn(fun() -> io:format("I am a process ~w~n!", [self()]) end).
 
spawnSort(List) ->
    {Even, Odd} = lists:partition(fun(I) -> I rem 2 == 0 end, List),
    spawn(?MODULE, sortPrint, ["Even", Even]),
    spawn(?MODULE, sortPrint, ["Odd", Odd]).
 
sortPrint(Print, List) ->
    io:format("~p sorted: ~w~n", [Print, lists:sort(List)]).
 
% run
1> c(spawning).
{ok,spawning}
2> spawning:spawnPrint().
I am process <0.42.0>
<0.42.0>
3> spawning:spawnPrintN(3).
I am process 3
I am process 2
I am process 1
done
4> spawning:spawnSpawn(3).
I am a 'lief'!
I am a 'lief'!
I am a 'lief'!
I am a 'lief'!
I am a 'lief'!
I am a 'lief'!
I am a 'lief'!
I am a 'lief'!
done
5> spawning:spawnSlashOneA().
I am process <0.58.0>
<0.58.0>
6> spawning:spawnSlashOneB().
I am a process <0.60.0>
<0.60.0>
7> spawning:spawnSort([4,6,3,7,9,8,2,1]).
"Even" sorted: [2,4,6,8]
"Odd" sorted: [1,3,7,9]
<0.63.0>

Creating Linked Processes

A very useful feature is to create a new process that is linked to the “parent” one. The link between them guarantees that if one of the two fails (finishes abnormally), the other one also stops executing (an 'EXIT' signal is propagated). This feature is very helpful because it reduces the need for “cleaning up” in case of a failure. Instead of explicitely handling an error, the “let it fail and let someone else handle it” philosophy can be used. The BIF(s) providing this functionality are the spawn_link/1|3.

Notice that linking can be done later, between two already running processes, using the BIF link/1. The difference is that the spawn_link executes spawning and linking atomically (either both operations succeed, or both fail).

link/1

Creates a bidirectional link between the calling process and another process (or port), if there is not such a link already. If a process attempts to create a link to itself, nothing is done. Returns true.

spawn_link/1|3

Provides the same functionality as spawn/1|3 with the addition that a link is atomically created between the caller and the newly spawned process.

spawn_link/1

Same call convention as spawn/1.

spawn_link/3

Same call convention as spawn/3.

Examples

spawnLink() ->
    spawn(fun spawnLink_/0).
 
spawnLink_() ->
    spawn_link(?MODULE, abnormalExit, []),
    justLoop().
 
justLoop() ->
    justLoop().
 
abnormalExit() ->
    timer:sleep(4000),
    erlang:kill(not_catched).
 
% run
1> c(spawning).
{ok,spawning}
2> Pid = spawning:spawnLink().  
<0.42.0>
3> erlang:is_process_alive(Pid).
true
4> erlang:is_process_alive(Pid).
true
5> erlang:is_process_alive(Pid).
=ERROR REPORT==== 7-May-2011::12:24:54 ===
Error in process <0.43.0> with exit value: {undef,[{erlang,kill,[not_
false
6> erlang:is_process_alive(Pid).
false

Other Processes’-related BIFs

There are several other BIFs related to processes. The following are some commonly used.

error/1

Called as error(Reason). Stops the execution of the calling process with the reason Reason, where Reason is any term. The actual exit reason will be {Reason, Where}, where Where is a list of the functions most recently called (the current function first). Since evaluating this function causes the process to terminate, it has no return value.

exit/1|2

Called as exit(Reason). Stops the execution of the calling process with the exit reason Reason, where Reason is any term. Since evaluating this function causes the process to terminate, it has no return value.

exit/2 is called as exit(Pid, Reason). Sends an exit signal with exit reason Reason to the process Pid.

The following behavior apply if Reason is any term except normal or kill:

If Pid is not trapping exits, Pid itself will exit with exit reason Reason. If Pid is trapping exits, the exit signal is transformed into a message {'EXIT', From, Reason} and delivered to the message queue of Pid. From is the pid of the process which sent the exit signal.

If Reason is the atom normal, Pid will not exit. If it is trapping exits, the exit signal is transformed into a message {'EXIT', From, normal} and delivered to its message queue.

If Reason is the atom kill, that is if exit(Pid, kill) is called, an untrappable exit signal is sent to Pid which will unconditionally exit with exit reason killed.

1> Rec = fun(F) -> F(F) end.
#Fun<erl_eval.6.13229925>
2> Loop = fun() -> Rec(Rec) end.
#Fun<erl_eval.20.67289768>
3> Pid = spawn(Loop).
<0.39.0>
4> erlang:is_process_alive(Pid).
true
5> exit(Pid, no_reason).
true
6> erlang:is_process_alive(Pid).
false

is_pid/1

Returns true if the argument is a pid, else false.

1> Pid = spawn(io, format, ["Hej~n"]).
Hej
<0.37.0>
2> is_pid(Pid).
true

is_process_alive/1

Called as is_process_alive(Pid). Pid must refer to a process at the local node. Returns true if the process exists and is alive, that is, is not exiting and has not exited. Otherwise, returns false.

13> is_process_alive(self()).
true

list_to_pid/1

Transforms the input string to a pid. This BIF is intended to be used for debugging and not in application development.

4> Pid == list_to_pid("<0.37.0>").
true

pid_to_list/1

Returns the textual representation of a pid. Again, this BIF is intended to be used for debugging only.

3> StringPid = pid_to_list(Pid).
"<0.37.0>"

register/2

Registers a process (or a port) with a name. This name can be later used to refer to the process.

7> ShellPid = self().         
<0.44.0>
8> register(shell, ShellPid).
true

registered/0

Returns a list with the names of all registered processes.

9> registered().
[init,shell,error_logger,rex,kernel_sup,inet_db,
 global_name_server,file_server_2,code_server,
 erl_prim_loader,user_drv,standard_error_sup,
 application_controller,standard_error,kernel_safe_sup,user,
 global_group]

self/0

One of the most commonly used BIF, returns the pid of the calling processes. As you will see in the next post (about messaging), self is used in almost every message send.

7> ShellPid = self().         
<0.44.0>

erlang:send/2|3

Sends a message to a process. We will see message sending in detail in the next post.

erlang:send_after/3

Sends a message after a given amount of time.

throw/1

Called as throw(Any). A non-local return from a function. If evaluated within a catch, catch will return the value Any.

1> throw(noooooo).                      
** exception throw: noooooo
2> try throw(yeeees) catch _:_ -> ok end.
ok
3> catch throw(yeeees).
yeeees

unlink/1

Removes the link between two processes. Returns true even if there exist no link.

unregister/1

Called as unregister(Name). Removes the association between the Name and the process which it is associated with.

11> unregister(shell).
true
12> registered().
[init,error_logger,rex,kernel_sup,inet_db,
 global_name_server,file_server_2,code_server,
 erl_prim_loader,user_drv,standard_error_sup,
 application_controller,standard_error,kernel_safe_sup,user,
 global_group]

whereis/1

Called as whereis(Name). Returns the pid of the process that is register with the name Name.

10> whereis(shell).
<0.44.0>

Next

Next post will be about message passing. After this post one should be able to unveil the “power of Erlang”.