aboutsummaryrefslogtreecommitdiffstats
path: root/lib
diff options
context:
space:
mode:
authorSverker Eriksson <[email protected]>2019-01-28 18:33:01 +0100
committerGitHub <[email protected]>2019-01-28 18:33:01 +0100
commit6af940b1c151f163f578ec74efa96f8002c0d820 (patch)
treec6ed74b2885ea6eb53970f86af5e55bb65667a8c /lib
parent1ea703443fa0bbc3aade0bb61fc96b2f0cf6b84c (diff)
parent7762660e35baba18f4fe8e83c8378db713541572 (diff)
downloadotp-6af940b1c151f163f578ec74efa96f8002c0d820.tar.gz
otp-6af940b1c151f163f578ec74efa96f8002c0d820.tar.bz2
otp-6af940b1c151f163f578ec74efa96f8002c0d820.zip
Merge PR-2108 from sverker/ets-doc-iter-oddity/OTP-15325
Add ETS doc note about subtle iteration oddities
Diffstat (limited to 'lib')
-rw-r--r--lib/stdlib/doc/src/ets.xml25
1 files changed, 25 insertions, 0 deletions
diff --git a/lib/stdlib/doc/src/ets.xml b/lib/stdlib/doc/src/ets.xml
index e67397c6fd..7594514b29 100644
--- a/lib/stdlib/doc/src/ets.xml
+++ b/lib/stdlib/doc/src/ets.xml
@@ -188,6 +188,31 @@
is used to keep the table fixated during the entire traversal.</p>
</item>
</list>
+ <note>
+ <p>Even though the access of a single object is always guaranteed to be
+ <seealso marker="#concurrency">atomic and isolated</seealso>, each traversal
+ through a table to find the next key is not done with such guarantees. This is often
+ not a problem, but may cause rare subtle "unexpected" effects if a concurrent
+ process inserts objects during a traversal. For example, consider one
+ process doing</p>
+<pre>
+ets:new(t, [ordered_set, named_table]),
+ets:insert(t, {1}),
+ets:insert(t, {2}),
+ets:insert(t, {3}),
+</pre>
+ <p>A concurrent call to <c>ets:first(t)</c>, done by another
+ process, may then in rare cases return <c>2</c> even though
+ <c>2</c> has never existed in the table ordered as the first key. In
+ the same way, a concurrent call to <c>ets:next(t, 1)</c> may return
+ <c>3</c> even though <c>3</c> never existed in the table
+ ordered directly after <c>1</c>.</p>
+ <p>Effects like this are improbable but possible. The probability will
+ further be reduced (if not vanish) if table option
+ <seealso marker="#new_2_write_concurrency"><c>write_concurrency</c></seealso>
+ is not enabled. This can also only be a potential concern for
+ <c>ordered_set</c> where the traversal order is defined.</p>
+ </note>
</section>
<section>