Change:
Now that we have at least one thing in it makes sense to move this to . EDIT ( Before stabilisation: [x] Decide on new function name ( or ) Stabilisation/deprecation: [x] Stabilise feature [] [x] Deprecate the function
currently invokes undefined behavior on x86 and x8664 targets without SSE2.
Are you sure? The sets the cpu to Yonah, which has SSE2.
if that was fixed we should close:
indeed, that's fixed, I've closed that issue.
Note that this isn't a tracking issue for the function itself; it's already stable and any bugs/qualms are reported separately. This is just for the renaming of it.
If this routine is moved to std::hint then the documentation of std::hint should be updated as well. It currently reads: Pause instruction is a hint to the CPU, not to the compiler.
I agree; it should be changed to "compiler and/or CPU".
It's been a few years since this landed, so in an effort to un-kitchen-sink the module I think we should: [ ] Inline the comments on onto and point the docs to instead [ ] Add a trivial busy-loop example that demonstrates how we want you to call it as [ ] Update the docs for the module to note that hints may be compile time or runtime [ ] Stabilize under that name [ ] Deprecate fcp merge This proposes stabilizing the following API: And deprecating the following API:
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [ ] [x] [x] [x] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
Assuming LLVM generates the x86 instruction, it actually has defined behavior on pre-SSE2 processors: it disassembles to a instruction, where the prefix is ignored by processors that don't understand the instruction.
One (not required for stabilisation) thing that may also useful to mention is that can also be used for embedded contexts, although I don't have any useful examples that aren't antequated x86 OS code, so, I'm sure that someone more active with embedded stuff can comment. Essentially, there are times where you can't outright halt the CPU until the next interrupt and you also have to wait for a condition to be met, and because you are the scheduler, obviously you can't yield to the scheduler.
Let's have at least 1 release cycle between stabilizing and deprecating , so proactive people can have 6 weeks to make the change at their own convenience without getting a warning?
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.
I don't think this should be closed yet seeing as the depreciation has not been done.
Reopening to track deprecation of .
Now that is deprecated I'll go ahead and close this tracking issue.

Discussion:
#![feature(raw_ref_op)] #![feature(rustc_attrs)] #![feature(receiver_trait)] <del> #![feature(renamed_spin_loop)] </del> #![feature(min_specialization)] #![feature(slice_ptr_get)] #![feature(slice_ptr_len)]

#![stable(feature = "core_hint", since = "1.27.0")] //! Hints to compiler that affects how code should be emitted or optimized. <ins> //! Hints may be compile time or runtime. </ins> use crate::intrinsics;

/// Otherwise, consider using the [`unreachable!`] macro, which does not allow /// optimizations but will panic when executed. /// <del> /// </del> /// # Example /// /// ```

unsafe { intrinsics::unreachable() } } <del> /// Emits a machine instruction hinting to the processor that it is running in busy-wait /// spin-loop ("spin lock"). </del> <ins> /// Emits a machine instruction to signal the processor that it is running in /// a busy-wait spin-loop ("spin lock"). /// /// Upon receiving the spin-loop signal the processor can optimize its behavior by, /// for example, saving power or switching hyper-threads. /// /// This function is different from [`thread::yield_now`] which directly /// yields to the system's scheduler, whereas `spin_loop` does not interact /// with the operating system. /// /// A common use case for `spin_loop` is implementing bounded optimistic /// spinning in a CAS loop in synchronization primitives. To avoid problems /// like priority inversion, it is strongly recommended that the spin loop is /// terminated after a finite amount of iterations and an appropriate blocking /// syscall is made. /// /// **Note**: On platforms that do not support receiving spin-loop hints this /// function does not do anything at all. /// /// # Examples </ins> /// <del> /// For a discussion of different locking strategies and their trade-offs, see /// [`core::sync::atomic::spin_loop_hint`]. </del> <ins> /// ``` /// use std::sync::atomic::{AtomicBool, Ordering}; /// use std::sync::Arc; /// use std::{hint, thread}; /// /// // A shared atomic value that threads will use to coordinate /// let live = Arc::new(AtomicBool::new(false)); /// /// // In a background thread we'll eventually set the value /// let bg_work = { ///     let live = live.clone(); ///     thread::spawn(move || { ///         // Do some work, then make the value live ///         do_some_work(); ///         live.store(true, Ordering::Release); ///     }) /// }; </ins> /// <del> /// **Note**: On platforms that do not support receiving spin-loop hints this function does not /// do anything at all. </del> <ins> /// // Back on our current thread, we wait for the value to be set /// while live.load(Ordering::Acquire) { ///     // The spin loop is a hint to the CPU that we're waiting, but probably ///     // not for very long ///     hint::spin_loop(); /// } /// /// // The value is now set /// # fn do_some_work() {} /// do_some_work(); /// bg_work.join()?; /// # Ok::<(), Box<dyn core::any::Any + Send + 'static>>(()) /// ``` </ins> /// <del> /// [`core::sync::atomic::spin_loop_hint`]: crate::sync::atomic::spin_loop_hint </del> <ins> /// [`thread::yield_now`]: ../../std/thread/fn.yield_now.html </ins> #[inline] <del> #[unstable(feature = "renamed_spin_loop", issue = "55002")] </del> <ins> #[stable(feature = "renamed_spin_loop", since = "1.49.0")] </ins> pub fn spin_loop() { #[cfg(all(any(target_arch = "x86", target_arch = "x86_64"), target_feature = "sse2"))] {

/// Signals the processor that it is inside a busy-wait spin-loop ("spin lock"). /// <del> /// Upon receiving spin-loop signal the processor can optimize its behavior by, for example, saving /// power or switching hyper-threads. /// /// This function is different from [`std::thread::yield_now`] which directly yields to the /// system's scheduler, whereas `spin_loop_hint` does not interact with the operating system. /// /// A common use case for `spin_loop_hint` is implementing bounded optimistic spinning in a CAS /// loop in synchronization primitives. To avoid problems like priority inversion, it is strongly /// recommended that the spin loop is terminated after a finite amount of iterations and an /// appropriate blocking syscall is made. </del> <ins> /// This function is expected to be deprecated in favor of /// [`hint::spin_loop`]. </ins> /// /// **Note**: On platforms that do not support receiving spin-loop hints this function does not /// do anything at all. /// <del> /// [`std::thread::yield_now`]: ../../../std/thread/fn.yield_now.html /// [`std::thread::sleep`]: ../../../std/thread/fn.sleep.html /// [`std::sync::Mutex`]: ../../../std/sync/struct.Mutex.html </del> <ins> /// [`hint::spin_loop`]: crate::hint::spin_loop </ins> #[inline] #[stable(feature = "spin_loop_hint", since = "1.24.0")] pub fn spin_loop_hint() {

#![feature(raw)] #![feature(raw_ref_macros)] #![feature(ready_macro)] <del> #![feature(renamed_spin_loop)] </del> #![feature(rustc_attrs)] #![feature(rustc_private)] #![feature(shrink_to)]