From 368d56010ae91a8b136c9eea5821ff3e5a7b79d3 Mon Sep 17 00:00:00 2001 From: Jon Gjengset Date: Wed, 12 Apr 2017 19:04:57 -0400 Subject: Rename compiler_barrier to compiler_fence This addresses concerns raised following the merge of #41092. Specifically: > The naming of these seems surprising: the multithreaded functions (and > both the single and multithreaded intrinsics themselves) are fences, > but this is a barrier. It's not incorrect, but the latter is both > inconsistent with the existing functions and slightly confusing with > another type in std (e.g., `Barrier`). `compiler_fence` carries the same semantic implication that this is a compiler-only operation, while being more in line with the fence/barrier concepts already in use in `std`. --- src/libcore/sync/atomic.rs | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) (limited to 'src/libcore/sync') diff --git a/src/libcore/sync/atomic.rs b/src/libcore/sync/atomic.rs index 0c70524ead2..fad58deecd4 100644 --- a/src/libcore/sync/atomic.rs +++ b/src/libcore/sync/atomic.rs @@ -1591,11 +1591,11 @@ pub fn fence(order: Ordering) { } -/// A compiler memory barrier. +/// A compiler memory fence. /// -/// `compiler_barrier` does not emit any machine code, but prevents the compiler from re-ordering +/// `compiler_fence` does not emit any machine code, but prevents the compiler from re-ordering /// memory operations across this point. Which reorderings are disallowed is dictated by the given -/// [`Ordering`]. Note that `compiler_barrier` does *not* introduce inter-thread memory +/// [`Ordering`]. Note that `compiler_fence` does *not* introduce inter-thread memory /// synchronization; for that, a [`fence`] is needed. /// /// The re-ordering prevented by the different ordering semantics are: @@ -1617,15 +1617,15 @@ pub fn fence(order: Ordering) { /// [`AcqRel`]: enum.Ordering.html#variant.AcqRel /// [`Relaxed`]: enum.Ordering.html#variant.Relaxed #[inline] -#[unstable(feature = "compiler_barriers", issue = "41091")] -pub fn compiler_barrier(order: Ordering) { +#[unstable(feature = "compiler_fences", issue = "41091")] +pub fn compiler_fence(order: Ordering) { unsafe { match order { Acquire => intrinsics::atomic_singlethreadfence_acq(), Release => intrinsics::atomic_singlethreadfence_rel(), AcqRel => intrinsics::atomic_singlethreadfence_acqrel(), SeqCst => intrinsics::atomic_singlethreadfence(), - Relaxed => panic!("there is no such thing as a relaxed barrier"), + Relaxed => panic!("there is no such thing as a relaxed compiler fence"), __Nonexhaustive => panic!("invalid memory ordering"), } } -- cgit 1.4.1-3-g733a5