<div dir="ltr"><div class="gmail_quote">2008/9/3 Valentin Micic <span dir="ltr"><<a href="mailto:valentin@pixie.co.za">valentin@pixie.co.za</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">






<div bgcolor="#ffffff">
<div><font face="Arial" size="2">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? </font></div>
<div></div></div></blockquote><div><br></div><div>We currently don't eliminate locking on private tables, mainly to support ets:info/1,2. We may try to eliminate locks</div><div>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</div>
<div>process is relatively cheap - it becomes expensive when several processes want to take the same lock.)</div><div> <br></div><div>However, we take different locks depending on the operation to perform. An operation that only reads from the table</div>
<div>(such as ets:lookup/2) will take a read lock, while an operation that will update the table (such as ets:insert/2) takes</div><div>a write lock. As long as no process has a write lock, any number of processes can take read locks. If a process takes</div>
<div>a write lock, it will be exclusive (i.e. no other processes can have either read or write locks).</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div bgcolor="#ffffff"><div> </div>
<div><font face="Arial" size="2">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. </font><font face="Arial" size="2"> 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.</font></div></div></blockquote><div><br></div><div>To access an ETS table, there are actually two locks that need to be taken.</div><div><br></div><div>1) A lock to access the meta table, to convert the numeric table identifier to a pointer to the actual table.</div>
<div><br></div><div>2) The lock for the table itself (either a read or write lock, as described above).</div><div><br></div><div>In R12B-4, the locking of the meta table has been optimized. There used to be only one lock for the meta table,</div>
<div>but there are now different locks for different parts of the table; therefore reducing the number of lock conflicts</div><div>for the meta table.</div><div><br></div><div>Therefore, if you have an application that accesses many different ETS tables, performance should be slightly better</div>
<div>in R12B-4.</div><div><br></div><div>If you have an application that accesses a single ETS table (and write to it frequently), there will still be lock</div><div>conflicts on the ETS table itself, so R12B-4 will not make much difference.</div>
<div><br></div><div>/Bjorn</div><div>-- <br></div></div>Björn Gustavsson, Erlang/OTP, Ericsson AB<br>
</div>