ETS & SMP
原文地址：
http://erlang.org/pipermail/erlang-questions/2008-September/037905.html
还是老大们解释这个比较轻松 源码参见 erl_db.c
2008/9/3 Valentin Micic <>
> Is ETS utilizing the same locking policy for all table types (namely:
> public, protected or private), and if so, would it be possible to relax
> locking for protected and private access?
>
We currently don't eliminate locking on private tables, mainly to support
ets:info/1,2. We may try to eliminate locks
on private tables in a future release. (But we are not sure it is
worthwhile. Taking a lock that is not already held by another
process is relatively cheap - it becomes expensive when several processes
want to take the same lock.)
However, we take different locks depending on the operation to perform. An
operation that only reads from the table
(such as ets:lookup/2) will take a read lock, while an operation that will
update the table (such as ets:insert/2) takes
a write lock. As long as no process has a write lock, any number of
processes can take read locks. If a process takes
a write lock, it will be exclusive (i.e. no other processes can have either
read or write locks).
> We've noticed that if more than one process requires an access to the same
> ets table (in SMP environment), the system slows down considerably due to
> the locking mechanism. It is quite possible to optimize this by fronting
> such a table with a dedicated process for request serialization -- works
> better as there is always only one proccess requesting a lock. Actually... as much as this works well for one table, not so sure how would
> such an "optimization" work for a large number of tables. By relaxing (or
> not having) a locking policy for (at least) tables with a private access,
> there would be no questions about it.
>
To access an ETS table, there are actually two 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, as described
above).
In R12B-4, the locking of the meta table has been optimized. There used to
be only one lock for the meta table,
but there are now different locks for different parts of the table;
therefore reducing the number of lock conflicts
for the meta table.
Therefore, if you have an application that accesses many different ETS
tables, performance should be slightly better
in R12B-4.
If you have an application that accesses a single ETS table (and write to it
frequently), there will still be lock
conflicts on the ETS table itself, so R12B-4 will not make much difference.
/Bjorn
--
Björn Gustavsson, Erlang/OTP, Ericsson AB
还是老大们解释这个比较轻松 源码参见 erl_db.c
2008/9/3 Valentin Micic <>
> Is ETS utilizing the same locking policy for all table types (namely:
> public, protected or private), and if so, would it be possible to relax
> locking for protected and private access?
>
We currently don't eliminate locking on private tables, mainly to support
ets:info/1,2. We may try to eliminate locks
on private tables in a future release. (But we are not sure it is
worthwhile. Taking a lock that is not already held by another
process is relatively cheap - it becomes expensive when several processes
want to take the same lock.)
However, we take different locks depending on the operation to perform. An
operation that only reads from the table
(such as ets:lookup/2) will take a read lock, while an operation that will
update the table (such as ets:insert/2) takes
a write lock. As long as no process has a write lock, any number of
processes can take read locks. If a process takes
a write lock, it will be exclusive (i.e. no other processes can have either
read or write locks).
> We've noticed that if more than one process requires an access to the same
> ets table (in SMP environment), the system slows down considerably due to
> the locking mechanism. It is quite possible to optimize this by fronting
> such a table with a dedicated process for request serialization -- works
> better as there is always only one proccess requesting a lock. Actually... as much as this works well for one table, not so sure how would
> such an "optimization" work for a large number of tables. By relaxing (or
> not having) a locking policy for (at least) tables with a private access,
> there would be no questions about it.
>
To access an ETS table, there are actually two 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, as described
above).
In R12B-4, the locking of the meta table has been optimized. There used to
be only one lock for the meta table,
but there are now different locks for different parts of the table;
therefore reducing the number of lock conflicts
for the meta table.
Therefore, if you have an application that accesses many different ETS
tables, performance should be slightly better
in R12B-4.
If you have an application that accesses a single ETS table (and write to it
frequently), there will still be lock
conflicts on the ETS table itself, so R12B-4 will not make much difference.
/Bjorn
--
Björn Gustavsson, Erlang/OTP, Ericsson AB