Atomic ets

[Ulf Wiger (AL/EAB)]

Robert Raschke wrote:

> If your application uses ets as a communication
> mechanism between processes, that is surely quite
> a sore design mistake.

At first sight, perhaps, but not necessarily.

> Where does this desire for programming with locks
> come from? Erlang has a much simpler way of
> dealing with parallelism.

But there are issues with using processes too.
I have suggested serializing all writes through
a gen_server, but still using ets. This has
some performance consequences, as Thomas Lindgren
has pointed out. They get further compounded if
you also pipe the reads through the same process,
(also because you get two term copies per read
instead of one) and if you don't, you may run into
consistency issues if one process writes, while
others read.

Storing the data in a functional data structure
on the process heap solves these issues for the 
most part, but then, if you have a very large 
data set, you will be at odds with the garbage
collector.

> But you do have to think about it,
> it's no use to take a book on PThreads and
> try to translate the algorithms directly.

I can assure you that that's not what's going
on here. Recall that Mats C won the Judges'
Prize in the Obfuscated Erlang competition,
so the guy really knows how to write an
Erlang program.  (:

(Seriously, after some 8 years working with
the AXD 301 as programmer, system manager, 
trouble shooter, profiler, etc., Mats has 
probably seen quite a few variations on the
topic of sharing data between processes.)

> Programming with locks or atomic regions always
> makes me think of the chaos that would ensue if
> there were only one library in the world with
> exactly one copy of every book and nobody is
> allowed their own.

For locks and atomic regions on steroids, check
out Simon Peyton Jones' "Composable Memory
Transactions" for Haskell. Actually, it's lock-
free programming, since all the ugly bits are
hidden under the covers.

atomic (do
   { s <- readTVar svar
   ; writeTVar svar "Wuggle"
   ; if length s < 10 then
        throw (AssertionFailed s)
     else ... }

It actually goes a lot further than what Mats
has proposed. Perhaps we should too...
Now, Erlang ain't Haskell, so it would perhaps
be a bit troublesome.

/Uffe