From a987af021d2d65b1b52e8e7759dbf030533e2bac Mon Sep 17 00:00:00 2001
From: Magnus Henoch <magnus.henoch@gmail.com>
Date: Tue, 11 Dec 2018 15:26:37 +0000
Subject: Fix typos in atomics.xml and counters.xml

---
 erts/doc/src/atomics.xml  |  2 +-
 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>
-- 
cgit v1.2.3