[erlang-questions] Re: Shared/Hybrid Heap

[Jachym Holecek]

# Morten Krogh 2010-10-17:
> 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.

"Apples and oranges" as they say. In your Erlang example:

  * Server explicitely agrees to provide some of its data.
  * Server is free to change this decision.
  * Client has to follow certain protocol to access this data.
  * All accesses to "shared" data are serialized.
  * It is "physically impossible" to obtain inconsistent snaphost of the data.
  * It is "physically impossible" to bypass server's control.
  * This is guaranteed at language level.
  * Your example is implemented completely within this well-defined semantics.

Contrast that with C:

  * All threads have equal access right to whole process address space.
  * Sychronization can be done, but is a mere convention (spinlocks/mutexes).
  * Data consistency can be done, but is a mere convetion (memory barriers).
  * At language level memory access semantics is more or less undefined.
  * Mutexes/memory barriers have to be done in assembly, ie. outside C.

A little more fun on the C side:

  * Compiler may reorder loads/stores (somewhat) unless you're careful.
  * CPU may reorder loads/stores (somewhat) unless you're careful.
  * Cache may do whatever it wants to (somewhat) unless you're careful.

Normally these thing will be taken care of by whatever threads implementation
you use (in architecture- and compiler-specific way), but if we're talking at
language level then there's no way (as far as I know) to achieve sane shared
memory semantics in C alone (if we admit the existence of concurrent threads
of execution which the language knows nothing about, of course).

But sure -- you can _model_ Erlang-like processes in C, and you can _model_
C-like shared memory in Erlang (including all of the quirks above if you
really wanted to). But at that point you're imposing correspondence of some
sort by brute force; as opposed to capturing inherent properties.

Just my two pence...

Regards,
	-- Jachym