Atomic ets

[Ulf Wiger (AL/EAB)]

Robert Raschke:
> I can understand the problems you get once you
> decide to go down the route of shared storage
> between parallel tasks.  I 

In many cases, it's not really shared storage, but
data that some process actually owns and controls.
A typical example of this is a resource handler.

> guess I myself would find it way too complicated.
>  My approach to dealing with shared storage is to
> use one of the two technologies that have solved this
> problem: databases or file systems.  I am lazy.

Of course, both will incur tremendous overhead compared
to ets.  ;-)

> In my mind, if you want to have a parallel application,
> then any kind of shared storage creates a bottleneck.
>  You can whittle away all you like it will remain a
> limiting factor.

In the applications for which Erlang was initially 
designed (telecoms), this type of bottleneck is 
more or less unavoidable, since you need to have 
some entity that keeps track of what hardware 
resources are allocated, and for what. One of the
most common patterns is client-server.


> Granted, the opposite approach of message passing
> and local storage has the overhead of copying lots
> of data.
 
Not necessarily. (:
In both "shared heap erlang" and "hybrid heap erlang",
(local) message passing is mostly done by reference
rather than by value.


> So, you have the choice of being limited by access
> to storage or duplication of storage.

Again, not necessarily duplication in the local case --
se above.

> But back to atomic ets.  Implementing such a thing
> would bring you halfway toward mnesia, wouldn't it?

Sort of, yes. It would probably address a fairly 
large portion of data manipulation where one would
otherwise choose mnesia.

/Uffe