[erlang-questions] Re: Shared/Hybrid Heap

Ulf Wiger ulf.wiger@REDACTED
Mon Oct 18 15:18:00 CEST 2010

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 

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.

Ulf W

Ulf Wiger, CTO, Erlang Solutions, Ltd.

More information about the erlang-questions mailing list