aboutsummaryrefslogtreecommitdiffstats
path: root/erts/doc/src/counters.xml
diff options
context:
space:
mode:
Diffstat (limited to 'erts/doc/src/counters.xml')
-rw-r--r--erts/doc/src/counters.xml26
1 files changed, 14 insertions, 12 deletions
diff --git a/erts/doc/src/counters.xml b/erts/doc/src/counters.xml
index ba4a22759f..36816bd68d 100644
--- a/erts/doc/src/counters.xml
+++ b/erts/doc/src/counters.xml
@@ -23,13 +23,13 @@
<title>counters</title>
</header>
- <module>counters</module>
+ <module since="OTP 21.2">counters</module>
<modulesummary>Counter Functions</modulesummary>
<description>
<p>This module provides a set of functions to do operations towards
shared mutable counter variables. The implementation does not utilize any
software level locking, which makes it very efficient for concurrent
- access. The counters are organized into arrays with the follwing
+ access. The counters are organized into arrays with the following
semantics:</p>
<list type="bulleted">
<item>
@@ -71,7 +71,7 @@
<funcs>
<func>
- <name name="new" arity="2"/>
+ <name name="new" arity="2" since="OTP 21.2"/>
<fsummary>Create counter array</fsummary>
<desc>
<p>Create a new counter array of <c><anno>Size</anno></c> counters.</p>
@@ -80,7 +80,7 @@
<taglist>
<tag><c>atomics</c> (Default)</tag>
<item><p>Counters will be sequentially consistent. If write
- operation A is done sequencially before write operation B, then a concurrent reader
+ operation A is done sequentially before write operation B, then a concurrent reader
may see none of them, only A, or both A and B. It cannot see only B.</p>
</item>
<tag><c>write_concurrency</c></tag>
@@ -90,7 +90,7 @@
inconsistency and memory consumption per counter.</p>
<p>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
+ sequentially 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.</p>
@@ -103,11 +103,13 @@
acceptable.</p>
</item>
</taglist>
+ <p>Counters are not tied to the current process and are automatically
+ garbage collected when they are no longer referenced.</p>
</desc>
</func>
<func>
- <name name="get" arity="2"/>
+ <name name="get" arity="2" since="OTP 21.2"/>
<fsummary>Read counter value</fsummary>
<desc>
<p>Read counter value.</p>
@@ -115,7 +117,7 @@
</func>
<func>
- <name name="add" arity="3"/>
+ <name name="add" arity="3" since="OTP 21.2"/>
<fsummary>Add to counter</fsummary>
<desc>
<p>Add <c><anno>Incr</anno></c> to counter at index
@@ -124,7 +126,7 @@
</func>
<func>
- <name name="sub" arity="3"/>
+ <name name="sub" arity="3" since="OTP 21.2"/>
<fsummary>Subtract from counter</fsummary>
<desc>
<p>Subtract <c><anno>Decr</anno></c> from counter at index
@@ -133,25 +135,25 @@
</func>
<func>
- <name name="put" arity="3"/>
+ <name name="put" arity="3" since="OTP 21.2"/>
<fsummary>Set counter to value</fsummary>
<desc>
<p>Write <c><anno>Value</anno></c> to counter at index
<c><anno>Ix</anno></c>.</p>
<note>
<p>Despite its name, the <c>write_concurrency</c> optimization does not
- improve <c>put</c>. A call to <c>put</c> is a relative heavy
+ improve <c>put</c>. A call to <c>put</c> is a relatively heavy
operation compared to the very lightweight and scalable <seealso
marker="#add/3"><c>add</c></seealso> and <seealso marker="#sub/3">
<c>sub</c></seealso>. The cost for a <c>put</c> with
- <c>write_concurrency</c> is lika a <seealso marker="#get/2"><c>get</c>
+ <c>write_concurrency</c> is like a <seealso marker="#get/2"><c>get</c>
</seealso> plus a <c>put</c> without <c>write_concurrency</c>.</p>
</note>
</desc>
</func>
<func>
- <name name="info" arity="1"/>
+ <name name="info" arity="1" since="OTP 21.2"/>
<fsummary>Get information about counter array.</fsummary>
<desc>
<p>Return information about a counter array in a map. The map