Linux kernel mirror (for testing) git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel os linux
1
fork

Configure Feed

Select the types of activity you want to include in your feed.

tools/memory-model: docs/README: Update introduction of locking.txt

Commit 9bc931e9e161 ("tools/memory-model: Add locking.txt and
glossary.txt to README") failed to mention the relation of the "Locking"
section in recipes.txt and locking.txt.

The latter is a detailed version of the former intended to be read on
its own.

Reword the description in README and add notes in locking.txt and
recipes.txt to clarify their relationship.

[ paulmck: Wordsmithing. ]

Signed-off-by: Akira Yokosawa <akiyks@gmail.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Acked-by: Andrea Parri <parri.andrea@gmail.com>

authored by

Akira Yokosawa and committed by
Paul E. McKenney
13a9a113 0af2f6be

+14 -2
+5 -2
tools/memory-model/Documentation/README
··· 23 23 that you need, and just want to get started with LKMM litmus 24 24 tests: litmus-tests.txt 25 25 26 - o You would like to access lock-protected shared variables without 27 - having their corresponding locks held: locking.txt 26 + o You need to locklessly access shared variables that are otherwise 27 + protected by a lock: locking.txt 28 + 29 + This locking.txt file expands on the "Locking" section in 30 + recipes.txt, but is self-contained. 28 31 29 32 o You are familiar with Linux-kernel concurrency, and would 30 33 like a detailed intuitive understanding of LKMM, including
+5
tools/memory-model/Documentation/locking.txt
··· 1 + [!] Note: 2 + This file expands on the "Locking" section of recipes.txt, 3 + focusing on locklessly accessing shared variables that are 4 + otherwise protected by a lock. 5 + 1 6 Locking 2 7 ======= 3 8
+4
tools/memory-model/Documentation/recipes.txt
··· 61 61 Locking 62 62 ------- 63 63 64 + [!] Note: 65 + locking.txt expands on this section, providing more detail on 66 + locklessly accessing lock-protected shared variables. 67 + 64 68 Locking is well-known and straightforward, at least if you don't think 65 69 about it too hard. And the basic rule is indeed quite simple: Any CPU that 66 70 has acquired a given lock sees any changes previously seen or made by any