[erlang-questions] Mnesia and concurrency
Sat Dec 23 17:04:50 CET 2006
Look in the source code of the distribution:
Kirill Zaborski wrote:
> 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
> source code for them - where is it?
> On 12/23/06, Yariv Sadan <> 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... :)
>> erlang-questions mailing list
> erlang-questions mailing list
More information about the erlang-questions