On Mon, 22 Mar 2021 08:15:14 -0700, Paul E. McKenney wrote:
> 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?
Thank you!
However, this patch conflicts with the removal of \index{} in glossary.tex
on my WIP branch.
Do you mind if I cherry pick it & rebase on the WIP branch, and
send you a pull request containing it later (maybe in a week or so)?
Thanks, Akira
>
> 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
>
