Wed Dec 14 20:29:03 CET 2005
--- 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
2. Use mnesia, abandon ets. Drawback: transactions are
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
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
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
More information about the erlang-questions