@@ -1666,10 +1666,14 @@ pub fn fence(order: Ordering) {
1666
1666
1667
1667
/// A compiler memory fence.
1668
1668
///
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.
1673
1677
///
1674
1678
/// The re-ordering prevented by the different ordering semantics are:
1675
1679
///
@@ -1678,6 +1682,16 @@ pub fn fence(order: Ordering) {
1678
1682
/// - with [`Acquire`], subsequent reads and writes cannot be moved ahead of preceding reads.
1679
1683
/// - with [`AcqRel`], both of the above rules are enforced.
1680
1684
///
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
+ ///
1681
1695
/// # Panics
1682
1696
///
1683
1697
/// Panics if `order` is [`Relaxed`].
@@ -1723,6 +1737,7 @@ pub fn fence(order: Ordering) {
1723
1737
/// [`Release`]: enum.Ordering.html#variant.Release
1724
1738
/// [`AcqRel`]: enum.Ordering.html#variant.AcqRel
1725
1739
/// [`Relaxed`]: enum.Ordering.html#variant.Relaxed
1740
+ /// [memory barriers]: https://www.kernel.org/doc/Documentation/memory-barriers.txt
1726
1741
#[ inline]
1727
1742
#[ stable( feature = "compiler_fences" , since = "1.22.0" ) ]
1728
1743
pub fn compiler_fence ( order : Ordering ) {
0 commit comments