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/ets.xml') 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.

+
-- cgit v1.2.3