tools/memory-model/Documentation/glossary.txt

Source file repositories/reference/linux-study-clean/tools/memory-model/Documentation/glossary.txt

File Facts

System
Linux kernel
Corpus path
tools/memory-model/Documentation/glossary.txt
Extension
.txt
Size
7449 bytes
Lines
179
Domain
Support Tooling And Documentation
Bucket
tools
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

This document contains brief definitions of LKMM-related terms.  Like most
glossaries, it is not intended to be read front to back (except perhaps
as a way of confirming a diagnosis of OCD), but rather to be searched
for specific terms.


Address Dependency:  When the address of a later memory access is computed
	based on the value returned by an earlier load, an "address
	dependency" extends from that load extending to the later access.
	Address dependencies are quite common in RCU read-side critical
	sections:

	 1 rcu_read_lock();
	 2 p = rcu_dereference(gp);
	 3 do_something(p->a);
	 4 rcu_read_unlock();

	In this case, because the address of "p->a" on line 3 is computed
	from the value returned by the rcu_dereference() on line 2, the
	address dependency extends from that rcu_dereference() to that
	"p->a".  In rare cases, optimizing compilers can destroy address
	dependencies.	Please see Documentation/RCU/rcu_dereference.rst
	for more information.

	See also "Control Dependency" and "Data Dependency".

Acquire:  With respect to a lock, acquiring that lock, for example,
	using spin_lock().  With respect to a non-lock shared variable,
	a special operation that includes a load and which orders that
	load before later memory references running on that same CPU.
	An example special acquire operation is smp_load_acquire(),
	but atomic_read_acquire() and atomic_xchg_acquire() also include
	acquire loads.

	When an acquire load returns the value stored by a release store
	to that same variable, (in other words, the acquire load "reads
	from" the release store), then all operations preceding that
	store "happen before" any operations following that load acquire.

	See also "Happens-Before", "Reads-From", "Relaxed", and "Release".

Coherence (co):  When one CPU's store to a given variable overwrites
	either the value from another CPU's store or some later value,
	there is said to be a coherence link from the second CPU to
	the first.

	It is also possible to have a coherence link within a CPU, which
	is a "coherence internal" (coi) link.  The term "coherence
	external" (coe) link is used when it is necessary to exclude
	the coi case.

	See also "From-reads" and "Reads-from".

Control Dependency:  When a later store's execution depends on a test
	of a value computed from a value returned by an earlier load,
	a "control dependency" extends from that load to that store.
	For example:

	 1 if (READ_ONCE(x))
	 2   WRITE_ONCE(y, 1);

	Here, the control dependency extends from the READ_ONCE() on
	line 1 to the WRITE_ONCE() on line 2.	Control dependencies are
	fragile, and can be easily destroyed by optimizing compilers.
	Please see control-dependencies.txt for more information.

	See also "Address Dependency" and "Data Dependency".

Cycle:	Memory-barrier pairing is restricted to a pair of CPUs, as the
	name suggests.	And in a great many cases, a pair of CPUs is all

Annotation

Implementation Notes