Vlad Dumitrescu XX (LN/EAB)
Tue Jun 14 13:24:00 CEST 2005
> From: Thomas Lindgren
> On the other hand, can we then claim that message
> passing without shared state is The Answer? As most
> experienced Erlang programmers know, ets and mnesia
> tend to show up after a while, so at the logical level
> shared state is still with us.
I apologize if it will show up that I was misunderstanding, but I feel a little confused by the above.
I don't think there is any non-trivial concurrent setting where data won't be shared at the 'logical level' you mention (if I understood correctly what you mean by that). Either the data is completely intenal to a process, or it is accessible from other processes. In the first case there's no concurrency, in the other it becomes shared at the logical level.
[ In my experience, ets and mnesia tend to appear because there are no other mutable data structures in Erlang, which is an artifact of the language design, not of the concurrency model. ]
So shared data is unavoidable at the logical level, because if nobody else needs it, we could just as well not compute anything :-)
The issue is how to manage access to that data: should the clients bear the burden of ensuring that the result will be correct, or should there be a central manager for that data, independent of the clients?
The former can be very efficient, but above a certain level of complexity it is very difficult to admninstrate.
The latter is much easier to get right, at the price of extra overhead.
An interesting analogy I just came to think of is that isolated processes with copy-semantics message passing is to "regular" multithreading what object-orientation is to spaghetti code.
Just my 2 cents worth.
More information about the erlang-questions