Upcoming article in Dr. Dobbs'

[Ulf Wiger (AL/EAB)]

Well, yes ets tables can be accessed directly by many processes,
but all reads and writes are atomic, while operations spanning
multiple objects are not. You could view ets as an optimization
of something that could equally well have been implemented in
Erlang using processes. One ets table could be modeled as a 
gen_server with a 'dict' or 'gb_trees' data structure. Named 
ets tables would require a registration process as well.
I once wrote an ets implementation in Erlang. Using named 
tables, it was about 30x slower than 'ets'.

If you want atomic operations on multiple objects, you can
either serialize all ets accesses using an erlang process,
or you can use Mnesia.

My main point is that ets really doesn't introduce any 
semantics that couldn't be implemented in erlang using 
processes. And the semantics of ets are not necessarily
"dirtier" than a lot of stuff that erlang programmers 
routinely do with processes.

/Uffe

> -----Original Message-----
> From: owner-erlang-questions@REDACTED
> [mailto:owner-erlang-questions@REDACTED]
> Sent: den 13 januari 2005 15:18
> To: 'erlang-questions@REDACTED'
> Subject: RE: Upcoming article in Dr. Dobbs'
> 
> 
> [Thought I'd pour some gasoline onto this thread again (:-)]
> 
> Joe Armstrong says:
> >  Erlang is the only language I know of that is well placed 
> to program multiCPUs
> > all other approaches use some form sharing and or locking 
> (which as I have said many
> > times before - is the root of all evil)
> 
> I heartily agree with the 'root of all evil' bit -- but 
> regrettably Erlang is plagued too:
> ets tables can be accessed directly from many processes. A 
> grave design mistake, in my opinion.
> The feature is there and it is being used. 
> 
> -- Thomas
> 
> 
> 
>