Atomic ets

[Thomas Lindgren]

--- Hal Snyder <hal@REDACTED> wrote:

> "Joe Armstrong (AL/EAB)"
> <joe.armstrong@REDACTED> writes:
> 
> >    Agggggggggggggggggggggggggghhhhhhhhhhhhhhhhhh
> >
> >    Verily verily verify I say untoo ye
> >
> >    Even thou thy hath vouchsafed a lock - and even
> though thy
> > thath promest to delivery it back - there will
> come a day
> > when the Great one will return and the lock will
> be raised
> > and there will be much gnashing of teeth and
> wailing and
> > the bones of the long dead will rise and dance on
> the graves
> > of the unfrocked bishops.
> 
> One great appeal of Erlang has been its avoidance of
> the Slough of
> (P)Threads and Mutexes into which my colleagues,
> many of whom are also
> deeply into OOP, have disappeared for months at a
> time. I shudder
> whenever purveyors of mutexes and other such evils
> make a run at the
> unspoiled atoll that is OTP.
> 
> Once someone snidely asked "With all this
> concurrency, what are
> Erlang's synchronization primitives", only to be
> crushed by the
> simplicity of the response: "send and receive".

Note that transactions provide another conceptually
simple approach. My prediction is that fine-grain,
hardware-assisted transactions will largely replace
locking in conventional systems. But not for a while;
the comp.arch. researchers have just gotten their
teeth into it.

So far the alternatives for "atomic ets" seem to be:

1. Serialize all non-atomic ets requests through a
gen_server. Drawback: needs extra trip to server.
(There is another design drawback: it can be a very
pessimistic "locking" regime for the data, leading to
excessive waiting.)

2. Use mnesia, abandon ets. Drawback: transactions are
more expensive.

3. Introduce critical sections, e.g., run a fun() to
completion. Drawback: it's a temptation to the
foolish. This approach seems attractive to me -- for
example: no need for explicit locking -- but the more
one wants to avoid mischief, the more it starts
looking like mnesia:transaction.

4. Use locks. Drawback: well-known to be difficult to
do right.

5. Introduce a magical new API more suited for
concurrent/atomic ets. Drawback: it doesn't exist yet
:-)

Out of these alternatives, as a rule of thumb, using
mnesia after all seems the solution with least scope
for trouble in an SMP system. Or, when suitable, use a
carefully-designed gen_server.

Best,
Thomas


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com