diff options
| author | Sverker Eriksson <[email protected]> | 2018-12-13 18:41:15 +0100 |
|---|---|---|
| committer | GitHub <[email protected]> | 2018-12-13 18:41:15 +0100 |
| commit | 9214b32fd0bb85d7f2e11149df3c0c1876f50403 (patch) | |
| tree | 783dc9b12bdfac0ad914700ff49c1a312f4d2c73 | |
| parent | 2bf2b7009905a880f514621e8912508055df437e (diff) | |
| parent | a987af021d2d65b1b52e8e7759dbf030533e2bac (diff) | |
| download | otp-9214b32fd0bb85d7f2e11149df3c0c1876f50403.tar.gz otp-9214b32fd0bb85d7f2e11149df3c0c1876f50403.tar.bz2 otp-9214b32fd0bb85d7f2e11149df3c0c1876f50403.zip | |
Merge PR-2050 from legoscia/atomics-counters-typos
Fix typos in atomics.xml and counters.xml
| -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> |