From 7762660e35baba18f4fe8e83c8378db713541572 Mon Sep 17 00:00:00 2001
From: Sverker Eriksson
Date: Mon, 21 Jan 2019 21:05:16 +0100
Subject: stdlib: Add ets doc note about subtle iteration oddities
as it has been made more relevant with the introduction of
write_concurrency for ordered_set.
---
lib/stdlib/doc/src/ets.xml | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
(limited to 'lib/stdlib/doc/src')
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.
+
+ Even though the access of a single object is always guaranteed to be
+ atomic and isolated, 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
+
+ets:new(t, [ordered_set, named_table]),
+ets:insert(t, {1}),
+ets:insert(t, {2}),
+ets:insert(t, {3}),
+
+ A concurrent call to ets:first(t), done by another
+ process, may then in rare cases return 2 even though
+ 2 has never existed in the table ordered as the first key. In
+ the same way, a concurrent call to ets:next(t, 1) may return
+ 3 even though 3 never existed in the table
+ ordered directly after 1.
+ Effects like this are improbable but possible. The probability will
+ further be reduced (if not vanish) if table option
+ write_concurrency
+ is not enabled. This can also only be a potential concern for
+ ordered_set where the traversal order is defined.
+