aboutsummaryrefslogtreecommitdiffstats
path: root/lib/stdlib/doc
diff options
context:
space:
mode:
authorSverker Eriksson <[email protected]>2013-01-23 16:46:08 +0100
committerSverker Eriksson <[email protected]>2013-01-23 16:46:08 +0100
commitb55ba329ba25ba4322efdf16053280a5f7dd1a5d (patch)
tree0029b4e0d85ce3ae4990a5cdb42d5353d9f3e756 /lib/stdlib/doc
parent0ab216f3dc96890b50f7430895ad5d7f6251f129 (diff)
downloadotp-b55ba329ba25ba4322efdf16053280a5f7dd1a5d.tar.gz
otp-b55ba329ba25ba4322efdf16053280a5f7dd1a5d.tar.bz2
otp-b55ba329ba25ba4322efdf16053280a5f7dd1a5d.zip
erts,stdlib: Increase number of locks for write_concurrency
Diffstat (limited to 'lib/stdlib/doc')
-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>