aboutsummaryrefslogtreecommitdiffstats
path: root/lib/stdlib
diff options
context:
space:
mode:
authorSverker Eriksson <[email protected]>2013-01-28 14:45:47 +0100
committerSverker Eriksson <[email protected]>2013-01-28 14:46:36 +0100
commit5d2db16748ee7ddc1f2ce83d86b650bc2df67224 (patch)
treeff8548698e71daeca7342d88202ad6cb03da3c92 /lib/stdlib
parentb59b81bf13b2666496a5789125f5d53fb4d2b88a (diff)
parentb55ba329ba25ba4322efdf16053280a5f7dd1a5d (diff)
downloadotp-5d2db16748ee7ddc1f2ce83d86b650bc2df67224.tar.gz
otp-5d2db16748ee7ddc1f2ce83d86b650bc2df67224.tar.bz2
otp-5d2db16748ee7ddc1f2ce83d86b650bc2df67224.zip
Merge branch 'sverk/ets-write_concurrency-locks'
* sverk/ets-write_concurrency-locks: erts,stdlib: Increase number of locks for write_concurrency OTP-10787
Diffstat (limited to 'lib/stdlib')
-rw-r--r--lib/stdlib/doc/src/ets.xml10
1 files changed, 7 insertions, 3 deletions
diff --git a/lib/stdlib/doc/src/ets.xml b/lib/stdlib/doc/src/ets.xml
index abaf64fb91..44c050a0d3 100644
--- a/lib/stdlib/doc/src/ets.xml
+++ b/lib/stdlib/doc/src/ets.xml
@@ -932,7 +932,8 @@ ets:select(Table,MatchSpec),</code>
If set to <c>true</c>, the table is optimized towards concurrent
write access. Different objects of the same table can be mutated
(and read) by concurrent processes. This is achieved to some degree
- at the expense of sequential access and concurrent reader performance.
+ at the expense of memory consumption and the performance of
+ sequential access and concurrent reading.
The <c>write_concurrency</c> option can be combined with the
<seealso marker="#new_2_read_concurrency">read_concurrency</seealso>
option. You typically want to combine these when large concurrent
@@ -944,8 +945,11 @@ ets:select(Table,MatchSpec),</code>
<seealso marker="#concurrency">atomicy and isolation</seealso>.
Functions that makes such promises over several objects (like
<c>insert/2</c>) will gain less (or nothing) from this option.</p>
- <p>Table type <c>ordered_set</c> is not affected by this option in current
- implementation.</p>
+ <p>In current implementation, table type <c>ordered_set</c> is not
+ affected by this option. Also, the memory consumption inflicted by
+ both <c>write_concurrency</c> and <c>read_concurrency</c> is a
+ constant overhead per table. This overhead can be especially large
+ when both options are combined.</p>
</item>
<item>
<marker id="new_2_read_concurrency"></marker>