From f504781a136b1992a1cee26a7da841892d796d91 Mon Sep 17 00:00:00 2001
From: Sverker Eriksson
Date: Wed, 21 Nov 2018 15:54:17 +0100
Subject: erts: Add counters:put/3
---
erts/doc/src/counters.xml | 36 ++++++++++++++++++++++++++++++++----
1 file changed, 32 insertions(+), 4 deletions(-)
(limited to 'erts/doc')
diff --git a/erts/doc/src/counters.xml b/erts/doc/src/counters.xml
index 85eedfdadc..ba4a22759f 100644
--- a/erts/doc/src/counters.xml
+++ b/erts/doc/src/counters.xml
@@ -85,14 +85,22 @@
write_concurrency
This is an optimization to achieve very efficient concurrent
- write operations at the expense of potential read inconsistency and memory
- consumption per counter.
+ add and sub operations at the expense of potential read
+ inconsistency and memory consumption per counter.
Read operations may see sequentially inconsistent results with
regard to concurrent write operations. Even if write operation A is done
sequencially before write operation B, a concurrent reader may see any
combination of A and B, including only B. A read operation is only
guaranteed to see all writes done sequentially before the read. No writes
are ever lost, but will eventually all be seen.
+ The typical use case for write_concurrency is when
+ concurrent calls to add and
+ sub toward the same counters
+ are very frequent, while calls to get
+ and put are much
+ less frequent. The lack of absolute read consistency must also be
+ acceptable.
@@ -110,7 +118,8 @@
Add to counter
- Add Incr to counter.
+ Add Incr to counter at index
+ Ix.
@@ -118,7 +127,26 @@
Subtract from counter
- Subtract Decr from counter.
+ Subtract Decr from counter at index
+ Ix.
+
+
+
+
+
+ Set counter to value
+
+ Write Value to counter at index
+ Ix.
+
+ Despite its name, the write_concurrency optimization does not
+ improve put. A call to put is a relative heavy
+ operation compared to the very lightweight and scalable add and
+ sub. The cost for a put with
+ write_concurrency is lika a get
+ plus a put without write_concurrency.
+
--
cgit v1.2.3