Commit 13a9a113 authored Mar 14, 2025 by Akira Yokosawa Committed by Paul E. McKenney Apr 22, 2025

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



Commit 9bc931e9 ("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>

parent 0af2f6be

tools/memory-model/Documentation/README

+5 −2

Original line number	Diff line number	Diff line
		@@ -23,8 +23,11 @@ o You are familiar with the Linux-kernel concurrency primitives
		that you need, and just want to get started with LKMM litmus
		tests: litmus-tests.txt

		o You would like to access lock-protected shared variables without
		having their corresponding locks held: locking.txt
		o You need to locklessly access shared variables that are otherwise
		protected by a lock: locking.txt

		This locking.txt file expands on the "Locking" section in
		recipes.txt, but is self-contained.

		o You are familiar with Linux-kernel concurrency, and would
		like a detailed intuitive understanding of LKMM, including

tools/memory-model/Documentation/locking.txt

+5 −0

Original line number	Diff line number	Diff line
		[!] Note:
		This file expands on the "Locking" section of recipes.txt,
		focusing on locklessly accessing shared variables that are
		otherwise protected by a lock.

		Locking
		=======

tools/memory-model/Documentation/recipes.txt

+4 −0

Original line number	Diff line number	Diff line
		@@ -61,6 +61,10 @@ usual) some things to be careful of:
		Locking
		-------

		[!] Note:
		locking.txt expands on this section, providing more detail on
		locklessly accessing lock-protected shared variables.

		Locking is well-known and straightforward, at least if you don't think
		about it too hard. And the basic rule is indeed quite simple: Any CPU that
		has acquired a given lock sees any changes previously seen or made by any