Atomic ets

[Thomas Lindgren]

--- Dave Smith <dizzyd@REDACTED> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> On Dec 14, 2005, at 12:29 PM, Thomas Lindgren wrote:
> 
> > 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.
> 
> If you will humor a Erlang newbie, what exactly is
> the difference  
> between a "transaction" and a mutex/critical
> section? 

OK, first, the comment above referred to mainstream
hardware research, not Erlang. I think stock hardware
will have support for "basic transactions" in a few
years (where you run a delimited segment of code and
either "commit" all memory operations or "abort" and
discard them). Compared to explicit locking, writing
correct code is just so much simpler in this model.

Anyway, compared to critical sections, full
transactions are also consistent, isolated and
durable. A transaction supports (more or less)
transparent fine-grain locking of multiple database
entries over multiple tables, ensures that the effects
are undone if the transaction aborts, etc etc.

> And, if the  
> difference is negligible, wouldn't introducing a
> transaction  
> construct or the other "atomic" ideas mentioned
> furthered down the  
> thread, just (re-)introduce the complexity of all
> the locking madness  
> Erlang currently shields us from?

Basically, transactions provide a safe wrapper for the
locking and associated operations on a shared memory
(or database). Your sanity won't be destroyed by
directly gazing at the locking code being executed
behind the scenes (cf. Gray, Reuter, TRANSACTION
PROCESSING :-).

Erlang has less need (or perhaps no need, some may
claim) for a shared memory/database, but in practice
it seems to creep back in for some purposes. Most of
the practical systems I have seen do use mnesia, for
example.

> The complaints about having to serialize to a
> gen_server seem odd to  
> me (again, a newbie :)). Mutexes introduce a similar
> sort of  
> serialization (i.e. you have to design carefully for
> speed/ 
> contention), yet have much more difficult semantics.

Yes, but if you funnel all writes to a table through a
server, you "lock the whole table" to, say, update a
single entry. I would prefer a more concurrent
solution when table operations are common. 

Best,
Thomas


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