[erlang-questions] Mnesia and concurrency

[Kirill Zaborski]

I'm also quite interested in the internals of ets implemenatation. I've
searched through the source code found ets.erl but it says there that the
greater part of ets functions are implemented as BIFs but I can not find the
source code for them - where is it?

Regards,
Kirill

On 12/23/06, Yariv Sadan <yarivvv@REDACTED> wrote:
>
> (I'm replying again to include the list)
>
> > A normal way to provide concurrent access to a critical
> > region in Erlang is to use a process to serialize the
> > accesses. This is really not much different from guarding
> > a critical region using semaphores - only much simpler.
> > It is also quite fast.
> >
> > Mnesia uses ets (or dets) tables, which can be accessed
> > concurrently by different processes. All reads and writes
> > are atomic, which means that they are serialized at the
> > lowest level (similar to always using write locks in a
> > threaded application).
>
>
> Thanks for the response. It gave me a much better understanding of how
> ets/Mnesia works.
>
> I'm interested in the mechanism behind ets, and how ets is different
> from other types of shared memory. It sounds like ets is basically a
> high-level shared memory implementation for Erlang, where that all
> reads and writes are atomic, and writes also lock the data to prevent
> other readers and/or writers from accessing it while it's being
> written. So, in a sense, ets is somewhere between regular shared
> memory, as in C/Java, and Haskell-style STM, which provides
> transactionality similar to the one Mnesia provides for ets. If I
> understand it correctly, then, it's not precise to say that Erlang
> processes can't have shared memory, but that the Erlang runtime
> provides a safe, high-level shared memory implementation called 'ets',
> that can also be accessed transactionally using Mnesia.
>
> This is all very interesting to me because the ets interface makes it
> seem as if an ets table is basically a dict hidden behind a
> gen_server, but ets actually has unique concurrency characteristics
> that can't be implemented in pure Erlang.
>
> I hope I'm not too far off track here... :)
>
> Regards,
> Yariv
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20061223/82c52695/attachment.htm>