What is Erlang's concurrency model actually?

Question

I was reading a paper recently Why Events are Bad. The paper is a comparative study of Event based and thread based highly concurrent servers and finally concludes stating that Threads are better than events in that scenario.

I find that I am not able to classify what sort of concurrency model erlang exposes. Erlang provides Light Weight Processes, but those processes are suspended most of the time until it has received some event/message of some sort.

/Arun

Answer 1

The Erlang concurrency model is based on the following premises:

• Lightweight concurrency. You should be able to efficiently create as many processes as you need for your application and you should be able efficiently to create and delete them when necessary. This means that processes are light and small and there is no need to have a process pool to save time.

• Asynchronous communication. All process communication is through asynchronous message passing, that's it, there is nothing else, nada.

• Error handling. The same way as as lightweight concurrency and asynchronous messages are fundamental to building concurrent systems error handling is fundamental to building robust systems. The primitives for this interact with concurrency and are part of the Erlang concurrency model.

• Process isolation. There is no shared state at all between processes, the only way to communicate is through message passing. This is fundamental to being able to build robust systems as it allows processes to crash without ruining it for other processes. Of course they may receive information that a process has crashed through the error handling mechanism but a crashed will never create inconsistent state in other processes. A corollary to this is that there is no global data.

These are the fundamental premises to Erlang's concurrency model. You may often see them expressed in different ways but they are basically the same. Erlang also has immutable data which is a BIG WIN but this is not really part of the concurrency model, message passing and process isolation are enough. In some circles this may be considered a heretical viewpoint.

As you can see Actors are only part of the model. Error handling is fundamental but often overlooked. Overlooking it means you have missed part of the point.

N.B. Erlang processes are proper processes/threads in that they have a life of their own and are not just a form of event driven coroutines. A process can happily go about its business and change its internal state without being driven by external events.

Answer 2

I guess it's called the Actor model.