[RFC PATCH 01/12] advsync: LOCK/UNLOCK -> ACQUIRE/RELEASE (part 1)

[Akira Yokosawa <akiyks@gmail.com>]

From c8b05232a7665495892fd11ec02e34b1b36b55ac Mon Sep 17 00:00:00 2001
From: Akira Yokosawa <akiyks@gmail.com>
Date: Sat, 25 Mar 2017 23:58:48 +0900
Subject: [RFC PATCH 01/12] advsync: LOCK/UNLOCK -> ACQUIRE/RELEASE (part 1)

This mostly corresponds to the former half of commit 2e4f5382d12a
("locking/doc: Rename LOCK/UNLOCK to ACQUIRE/RELEASE")[1] in Linux
kernel repository, but only replaces what is present in perfbook
now.

Note:"memory-barriers.txt" has more details not included here.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2e4f5382d12a

Signed-off-by: Akira Yokosawa <akiyks@gmail.com>
---
 advsync/memorybarriers.tex | 28 ++++++++++++++--------------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/advsync/memorybarriers.tex b/advsync/memorybarriers.tex
index 165b5cb..29d3af1 100644
--- a/advsync/memorybarriers.tex
+++ b/advsync/memorybarriers.tex
@@ -1555,36 +1555,36 @@ There are a couple of types of implicit memory barriers, so called
 because they are embedded into locking primitives:

 \begin{enumerate}
-\item	LOCK operations and
-\item	UNLOCK operations.
+\item	ACQUIRE operations and
+\item	RELEASE operations.
 \end{enumerate}

-\paragraph{LOCK Operations}
+\paragraph{ACQUIRE Operations}

-A lock operation acts as a one-way permeable barrier.
+An acuire operation acts as a one-way permeable barrier.
 It guarantees that all memory
-operations after the LOCK operation will appear to happen after the LOCK
+operations after the ACQUIRE operation will appear to happen after the ACQUIRE
 operation with respect to the other components of the system.

-Memory operations that occur before a LOCK operation may appear to happen
+Memory operations that occur before an ACQUIRE operation may appear to happen
 after it completes.

-A LOCK operation should almost always be paired with an UNLOCK operation.
+An ACQUIRE operation should almost always be paired with a RELEASE operation.

-\paragraph{UNLOCK Operations}
+\paragraph{RELEASE Operations}

-Unlock operations also act as a one-way permeable barrier.
+Release operations also act as a one-way permeable barrier.
 It guarantees that all
-memory operations before the UNLOCK operation will appear to happen before
-the UNLOCK operation with respect to the other components of the system.
+memory operations before the RELEASE operation will appear to happen before
+the RELEASE operation with respect to the other components of the system.

-Memory operations that occur after an UNLOCK operation may appear to
+Memory operations that occur after a RELEASE operation may appear to
 happen before it completes.

-LOCK and UNLOCK operations are guaranteed to appear with respect to each
+ACQUIRE and RELEASE operations are guaranteed to appear with respect to each
 other strictly in the order specified.

-The use of LOCK and UNLOCK operations generally precludes the need for
+The use of ACQUIRE and RELEASE operations generally precludes the need for
 other sorts of memory barrier (but note the exceptions mentioned in the
 Section~\ref{sec:advsync:Device Operations}).

-- 
2.7.4