diff options
| author | Magnus Henoch <[email protected]> | 2018-12-11 15:26:37 +0000 |
|---|---|---|
| committer | Magnus Henoch <[email protected]> | 2018-12-11 15:48:07 +0000 |
| commit | a987af021d2d65b1b52e8e7759dbf030533e2bac (patch) | |
| tree | 124e9d45b051de1ac1b6cb980731a61595bd9d8a /erts/doc/src | |
| parent | 3825199794da28d79b21052a2e69e2335921d55e (diff) | |
| download | otp-a987af021d2d65b1b52e8e7759dbf030533e2bac.tar.gz otp-a987af021d2d65b1b52e8e7759dbf030533e2bac.tar.bz2 otp-a987af021d2d65b1b52e8e7759dbf030533e2bac.zip | |
Fix typos in atomics.xml and counters.xml
Diffstat (limited to 'erts/doc/src')
| -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> |