[erlang-questions] Re: Shared/Hybrid Heap

[Ulf Wiger]

On 18 Oct 2010, at 12:28, Morten Krogh wrote:

>> And we haven't even discussed the problem of one of these processes
>> crashing yet. With two concurrent contexts explicitly writing to the same
>> block of memory, ensuring the integrity of that memory block if one of
>> the contexts throws an exception will be very, very hard. This is where
>> Erlang's "share nothing" philosophy really pays off. The VM may decide
>> to share data under the hood, but as a programmer, you can be absolutely
>> certain that the death of another process - even in the same memory space
>> - cannot ruin the integrity of your own data. It really is as if you had your own
>> distinct copies of everything.
>> 
> This is where we disagree strongly. I am saying that you get the same problems again just at a higher level.

Your claim was that there are no fundamental differences between
Erlang and C in regard to shared memory. If you care to limit that claim
to a particular set of problems that can arise in both environments, it's
entirely uncontroversial. Otherwise, it becomes difficult to discuss the 
matter.

Fundamentally, I'd say that Erlang is more similar to C programs running in 
separate OS processes, not sharing memory. Many of the problems you bring
up can happen there too. What cannot happen is that one process directly 
modifies and corrupts the memory of another process.

Also, even in that case, the two processes will be sharing physical memory
at some level, but what is important is that the _user-level program_ cannot 
exploit this. This (fundamental) difference typically has the practical consequence
that if you suffer a crash in a multithreaded shared-memory environment, all 
bets are off, whereas if you have memory protection boundaries between the 
processes, you may be able to recover.

Needless to say, this is often not enough, and there may be inconsistencies and
deadlocks at higher levels.

BR,
Ulf W

Ulf Wiger, CTO, Erlang Solutions, Ltd.
http://erlang-solutions.com