diff options
| author | Sverker Eriksson <[email protected]> | 2018-12-13 18:43:48 +0100 |
|---|---|---|
| committer | Sverker Eriksson <[email protected]> | 2018-12-13 18:43:48 +0100 |
| commit | 9959b13153a30abbaef43c03743fc05f4a1990e7 (patch) | |
| tree | bac60b4553f09f2a4d8bd90cb293d8254b6266e4 | |
| parent | 56f93ad10f89e6b8d3372e45127ec9fdc3fca35b (diff) | |
| parent | 9214b32fd0bb85d7f2e11149df3c0c1876f50403 (diff) | |
| download | otp-9959b13153a30abbaef43c03743fc05f4a1990e7.tar.gz otp-9959b13153a30abbaef43c03743fc05f4a1990e7.tar.bz2 otp-9959b13153a30abbaef43c03743fc05f4a1990e7.zip | |
Merge branch 'maint'
| -rw-r--r-- | erts/doc/src/atomics.xml | 2 | ||||
| -rw-r--r-- | erts/doc/src/counters.xml | 10 |
2 files changed, 6 insertions, 6 deletions
diff --git a/erts/doc/src/atomics.xml b/erts/doc/src/atomics.xml index 3fca92fb97..82b8ab4aa6 100644 --- a/erts/doc/src/atomics.xml +++ b/erts/doc/src/atomics.xml @@ -30,7 +30,7 @@ mutable atomic variables. The implementation utilizes only atomic hardware instructions without any software level locking, which makes it very efficient for concurrent access. The atomics are organized into - arrays with the follwing semantics:</p> + arrays with the following semantics:</p> <list type="bulleted"> <item> <p>Atomics are 64 bit integers.</p> diff --git a/erts/doc/src/counters.xml b/erts/doc/src/counters.xml index ba4a22759f..a7b6c61457 100644 --- a/erts/doc/src/counters.xml +++ b/erts/doc/src/counters.xml @@ -29,7 +29,7 @@ <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> @@ -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> @@ -140,11 +140,11 @@ <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> |