On Mon, Mar 22, 2021 at 02:50:38PM +0900, Akira Yokosawa wrote:
> On Sun, 21 Mar 2021 10:03:49 +0900, Akira Yokosawa wrote:
> > On Sat, 20 Mar 2021 12:23:23 -0700, Paul E. McKenney wrote:
> >> On Sun, Mar 21, 2021 at 12:50:43AM +0900, Akira Yokosawa wrote:
> >>> On Sun, 21 Mar 2021 00:24:46 +0900, Akira Yokosawa wrote:
> >>>> Signed-off-by: Akira Yokosawa <akiyks@xxxxxxxxx>
> >>>> ---
> >>>> debugging/debugging.tex | 2 +-
> >>>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/debugging/debugging.tex b/debugging/debugging.tex
> >>>> index fd52d9e7..3f697f58 100644
> >>>> --- a/debugging/debugging.tex
> >>>> +++ b/debugging/debugging.tex
> >>>> @@ -755,7 +755,7 @@ access to data.
> >>>> The Kernel Concurrency Sanitizer (KCSAN)~\cite{JonathanCorbet2019KCSAN}
> >>>> uses existing markings such as \co{READ_ONCE()} and \co{WRITE_ONCE()}
> >>>> to determine which concurrent accesses deserve warning messages.
> >>>> -KCSAN has a significant false-positive rate, especially in from the
> >>>> +KCSAN has a significant false-positive rate, especially from the
> >>>> viewpoint of developers thinking in terms of C as assembly language
> >>>> with additional syntax.
> >>>> KCSAN therefore provides a \co{data_race()} construct to forgive
> >>>>
> >>>
> >>> Paul,
> >>>
> >>> I caught this one while searching the usage of "data race" in perfbook.
> >>> I thought "data race" also deserves an entry in Glossaries, especially
> >>> because our use of "data race" is heavily related to compiler
> >>> optimizations and somewhat stricter than the common definition
> >>> found on the web.
> >>>
> >>> The first of data race in Section 4.2.2 (just before QQ4.8) does
> >>> not (explicitly) talk about optimizations.
> >>>
> >>> Would it be possible for you to come up with some concise definition
> >>> of data race which will fit as an entry in the Glossaries?
> >>
> >> How about like the following?
> >
> > Looks good to me!
>
> It looked good, but I've found that there is no mention of "marked access"
> in the whole text (except for Glossaries) in perfbook at the moment.
>
> "Marked access", "unmarked load", and so on are used in
> ordering.txt to be added to LKMM documentation.
> They are going to appear in perfbook, I suppose.
>
> How about adding "Plain Access" to the Glossaries as well
> and amend the definition of "Data Race" using "plain access".
Good point! Like this?
Thanx, Paul
------------------------------------------------------------------------
commit b91c52cd1a93777ba91300d739e498bae9c49aea
Author: Paul E. McKenney <paulmck@xxxxxxxxxx>
Date: Mon Mar 22 08:13:24 2021 -0700
Glossary: Add an entry for "Plain Access"
The book uses "plain access", so it deserves a glossary entry.
And of course "marked access" is its antonym, more or less.
Reported-by: Akira Yokosawa <akiyks@xxxxxxxxx>
Signed-off-by: Paul E. McKenney <paulmck@xxxxxxxxxx>
diff --git a/glossary.tex b/glossary.tex
index e6aa612..bbef382 100644
--- a/glossary.tex
+++ b/glossary.tex
@@ -174,11 +174,11 @@
A race condition in which several CPUs or threads access
a variable concurrently, and in which at least one of those
accesses is a store and at least one of those accesses
- is unmarked.
+ is a plain access.
It is important to note that while the presence of data races
often indicates the presence of bugs, the absence of data races
in no way implies the absence of bugs.
- (See ``Marked access''.)
+ (See ``Plain access''.)
\item[Deadlock Free:]\index{Deadlock free}
A forward-progress guarantee in which, in the absence of
failures, at least one thread makes progress within a finite
@@ -301,9 +301,9 @@
macro, such as \co{READ_ONCE()}, \co{WRITE_ONCE()},
\co{atomic_inc()}, and so on, in order to protect that access
from compiler and/or hardware optimizations.
- In contrast, an unmarked access simply mentions the name of
+ In contrast, a plain access simply mentions the name of
the object being accessed, so that in the following, line~2
- is the unmarked equivalent of line~1:
+ is the plain-access equivalent of line~1:
\begin{VerbatimN}
WRITE_ONCE(a, READ_ONCE(b) + READ_ONCE(c));
a = b + c;
@@ -393,6 +393,10 @@
In the 1960s through the early 1980s, pipelined CPUs were the
province of supercomputers, but started appearing in microprocessors
(such as the 80486) in the late 1980s.
+\item[Plain Access:]\index{Plain access}
+ A source-code memory access that simply mentions the name of
+ the object being accessed.
+ (See ``Marked access''.)
\item[Process Consistency:]\index{Process consistency}
A memory-consistency model in which each CPU's stores appear to
occur in program order, but in which different CPUs might see
