[erlang-questions] Mnesia and concurrency

[Serge Aleynikov]

Look in the source code of the distribution:

./erts/emulator/beam/erl_db.c

Serge

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 
> 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
>>
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions