Skip to content

Commit 73bd10a

Browse files
budziqdtolnay
authored andcommitted
Added more text from unstable-book to compiler_fence docs
1 parent f7d4d84 commit 73bd10a

File tree

1 file changed

+19
-4
lines changed

1 file changed

+19
-4
lines changed

src/libcore/sync/atomic.rs

Lines changed: 19 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -1666,10 +1666,14 @@ pub fn fence(order: Ordering) {
16661666

16671667
/// A compiler memory fence.
16681668
///
1669-
/// `compiler_fence` does not emit any machine code, but prevents the compiler from re-ordering
1670-
/// memory operations across this point. Which reorderings are disallowed is dictated by the given
1671-
/// [`Ordering`]. Note that `compiler_fence` does *not* introduce inter-thread memory
1672-
/// synchronization; for that, a [`fence`] is needed.
1669+
/// `compiler_fence` does not emit any machine code, but restricts the kinds
1670+
/// of memory re-ordering the compiler is allowed to do. Specifically, depending on
1671+
/// the given [`Ordering`] semantics, the compiler may be disallowed from moving reads
1672+
/// or writes from before or after the call to the other side of the call to
1673+
/// `compiler_fence`. Note that it does **not** prevent the *hardware*
1674+
/// from doing such re-ordering. This is not a problem in a single-threaded,
1675+
/// execution context, but when other threads may modify memory at the same
1676+
/// time, stronger synchronization primitives such as [`fence`] are required.
16731677
///
16741678
/// The re-ordering prevented by the different ordering semantics are:
16751679
///
@@ -1678,6 +1682,16 @@ pub fn fence(order: Ordering) {
16781682
/// - with [`Acquire`], subsequent reads and writes cannot be moved ahead of preceding reads.
16791683
/// - with [`AcqRel`], both of the above rules are enforced.
16801684
///
1685+
/// `compiler_fence` is generally only useful for preventing a thread from
1686+
/// racing *with itself*. That is, if a given thread is executing one piece
1687+
/// of code, and is then interrupted, and starts executing code elsewhere
1688+
/// (while still in the same thread, and conceptually still on the same
1689+
/// core). In traditional programs, this can only occur when a signal
1690+
/// handler is registered. In more low-level code, such situations can also
1691+
/// arise when handling interrupts, when implementing green threads with
1692+
/// pre-emption, etc. Curious readers are encouraged to read the Linux kernel's
1693+
/// discussion of [memory barriers].
1694+
///
16811695
/// # Panics
16821696
///
16831697
/// Panics if `order` is [`Relaxed`].
@@ -1723,6 +1737,7 @@ pub fn fence(order: Ordering) {
17231737
/// [`Release`]: enum.Ordering.html#variant.Release
17241738
/// [`AcqRel`]: enum.Ordering.html#variant.AcqRel
17251739
/// [`Relaxed`]: enum.Ordering.html#variant.Relaxed
1740+
/// [memory barriers]: https://www.kernel.org/doc/Documentation/memory-barriers.txt
17261741
#[inline]
17271742
#[stable(feature = "compiler_fences", since = "1.22.0")]
17281743
pub fn compiler_fence(order: Ordering) {

0 commit comments

Comments
 (0)