Getting concurrency

[Vlad Dumitrescu XX (LN/EAB)]

Hi,

> 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.
best regards,
Vlad