views:

229

answers:

2

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

+6  A: 

I guess it's called the Actor model.

Yasir Arsanukaev
@Yasir I agree, but the Actor model looks like a hybrid of the event and thread model..
arun_suresh
@Arun: Actor model from e. g. Erlang uses so called Green threads, scheduled rather in VM than in OS, so they are vastly lighter weight. I believe Threading model allows you to modify some kind of global state (e. g. variables) concurrently, while in Actor model every actor can only change its own state depending on message it received. I think Actor model is more flexible than Event model, since you don't need to rewrite actors' code in order to receive messages from more than one sender.
Yasir Arsanukaev
+7  A: 

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.

rvirding
@rvirding thanks.. that certainly cleared up quite a bit. Actually I was kind of confused with this paper : http://lamp.epfl.ch/~phaller/doc/haller07actorsunify.pdf .. Which basically talks about how Actors in Scala are an attempt at unifying threads and events and considering the fact that the Actors are inspired by Erlang processes, I assumed that was motivation for Light weight processes in the first place..
arun_suresh
No, funny thing is that even though Actors are older than Erlang we had not heard of them at the time. It was only later when people mentioned that Erlang followed the Actor model that we found out.
rvirding