[erlang-questions] Questions about ETS locking

Sverker Eriksson sverker@REDACTED
Thu May 10 10:52:49 CEST 2012


By default, several concurrent readers can access the same table at the 
same time.

Option read_concurrency will make concurrent reading even more faster at 
the expense of a slower operation when switching between "read mode" and 
"write mode".

http://www.erlang.org/doc/man/ets.html#new_2_read_concurrency


/Sverker, Erlang/OTP


skyman wrote:
> Oh, I see. Thanks a lot.
> Another question: is default reading from an ETS table is concurrency? what's the difference between the default reading and option read_concurrency?
> Thank you!
>
>
>
>
>
> At 2012-05-07 20:55:39,"Sverker Eriksson" <sverker@REDACTED> wrote:
>   
>> skyman wrote:
>>     
>>> Hi all,
>>>
>>>
>>> I know when access an ETS table, there are wo locks that need to be taken.
>>> 1) A lock to access the meta table, to convert the numeric table identifier
>>> to a pointer to the actual table.
>>>
>>> 2) The lock for the table itself (either a read or write lock).
>>> I know in the SMP mode£¬an ETS table must be locked when access it, but I don't make sure that must an ETS table be locked in the non-SMP mode(only one scheduler)?
>>>   
>>>       
>> An SMP-enabled emulator will do the locking even when running only one 
>> scheduler.
>> A non-SMP emulator (erl -smp disable) will not do any locking.
>>
>>     
>>> Another question is, whether the default ETS table locking is on table-level or on record-level?
>>> Thanks in advance!
>>>
>>>   
>>>       
>> The default locking is on table-level, allowing only one update 
>> operation at a time per table.
>> Table option write_concurrency will enable locking on a more fine 
>> grained level, allowing concurrent update operations. In current 
>> implementation 16 locks per table is used, which result in a probability 
>> of 1/16 that two random keys will collide on the same lock.
>>
>> Option write_concurrency have no effect on ordered_set's.
>>
>>
>> /Sverker, Erlang/OTP Ericsson
>>
>>
>>     





More information about the erlang-questions mailing list