[erlang-questions] Re: Shared/Hybrid Heap

[Morten Krogh]

  Hi Steve

On 10/17/10 5:52 PM, Steve Davis wrote:
> On Oct 17, 6:30 am, Morten Krogh<m...@REDACTED>  wrote:
>> Actually shared memory is a bad wording. It should be called "C like
>> pointer access to the data".
> That sounds even worse! Have we learned nothing from all that history
> of thread-aches in mainstream computing?
>

The point here is that all languages including Erlang has shared memory 
with any reasonably general definition
of shared memory. Erlangers often make the claim that erlang doesn't 
have shared memory. I can only understand that point
if shared memory is defined rather strictly as "C like pointers to an 
address". How would you define it such that
Erlang doesn't have it but other languages do.

The problem is of course that a process like this

loop(State) ->
     receive
     {From, get, X} ->
         From ! {result, get(X, State)},
         loop(State)

     etc.....

Behaves exactly like shared memory seen from other processes point of view.

Writing

Pid ! {self(), get, 27}
receive
     {result, Result} ->
         Result
end.

is like writing

get(X, Pid) in C (the language) where Pid is pointer to a shared data 
structure in C

in C.

All issues with locks, deadlocks etc are the same.
Locks are needed when you want to send two messages to a process without 
any one else touching it in between, or when the state of two processes 
must be coordinated.
A deadlock occurs, for instance, when two processes are waiting for each 
other.

An Erlang process contains more data than a single memory address, which 
is an advantage but it is qualitatively the same, and you can never 
serialize all data in one process.

>> The only real question is whether erlang should have a way for
>> one process to read state of another...
> I'm not sure you have fully thought through the implications of that
> suggestion! ;) More concretely, consider the meaning of the java
> keyword "volatile", what issue it points us to, and how that issue has
> deep implications for the entire Java platform.
>

Of course, I would never have all processes introspect all other 
processes. The example at hand was a large shared data structure, where 
directly reading state would save
all the boilerplate above, and give you faster performance. You would 
have to say, that the pople who impemented ETS haven't thought tthings 
through as well or what?
Do you think that Erlang is a worse language because of ETS? I think it 
is better, and Erlang could have much more of that for my part.


Best regards,

Morten.