all FX functions are now safe wrapped and I added the crate to the docs also it is added to the prelude
This commit is contained in:
parent
522844499e
commit
b9e517fa21
1649 changed files with 72257 additions and 0 deletions
57
docs/doc/atomic_polyfill/fn.compiler_fence.html
Normal file
57
docs/doc/atomic_polyfill/fn.compiler_fence.html
Normal file
|
|
@ -0,0 +1,57 @@
|
|||
<!DOCTYPE html><html lang="en"><head><meta charset="utf-8"><meta name="viewport" content="width=device-width, initial-scale=1.0"><meta name="generator" content="rustdoc"><meta name="description" content="A compiler memory fence."><title>compiler_fence in atomic_polyfill - Rust</title><link rel="preload" as="font" type="font/woff2" crossorigin href="../static.files/SourceSerif4-Regular-46f98efaafac5295.ttf.woff2"><link rel="preload" as="font" type="font/woff2" crossorigin href="../static.files/FiraSans-Regular-018c141bf0843ffd.woff2"><link rel="preload" as="font" type="font/woff2" crossorigin href="../static.files/FiraSans-Medium-8f9a781e4970d388.woff2"><link rel="preload" as="font" type="font/woff2" crossorigin href="../static.files/SourceCodePro-Regular-562dcc5011b6de7d.ttf.woff2"><link rel="preload" as="font" type="font/woff2" crossorigin href="../static.files/SourceSerif4-Bold-a2c9cd1067f8b328.ttf.woff2"><link rel="preload" as="font" type="font/woff2" crossorigin href="../static.files/SourceCodePro-Semibold-d899c5a5c4aeb14a.ttf.woff2"><link rel="stylesheet" href="../static.files/normalize-76eba96aa4d2e634.css"><link rel="stylesheet" href="../static.files/rustdoc-cb6f1f67f1bcd037.css" id="mainThemeStyle"><meta name="rustdoc-vars" data-root-path="../" data-static-root-path="../static.files/" data-current-crate="atomic_polyfill" data-themes="" data-resource-suffix="" data-rustdoc-version="1.73.0-nightly (8131b9774 2023-08-02)" data-channel="nightly" data-search-js="search-6dfdfced5eff6596.js" data-settings-js="settings-de11bff964e9d4e5.js" data-settings-css="settings-8c76f75bfb6bd192.css" data-theme-light-css="light-6d2c9675f3d09c26.css" data-theme-dark-css="dark-45ceb8f2e522f4d1.css" data-theme-ayu-css="ayu-fd19013d6ce078bf.css" ><script src="../static.files/storage-db41da1a38ea3cb8.js"></script><script defer src="sidebar-items.js"></script><script defer src="../static.files/main-0795b7d26be81095.js"></script><noscript><link rel="stylesheet" media="(prefers-color-scheme:light)" href="../static.files/light-6d2c9675f3d09c26.css"><link rel="stylesheet" media="(prefers-color-scheme:dark)" href="../static.files/dark-45ceb8f2e522f4d1.css"><link rel="stylesheet" href="../static.files/noscript-cffde32267a19fd6.css"></noscript><link rel="alternate icon" type="image/png" href="../static.files/favicon-16x16-8b506e7a72182f1c.png"><link rel="alternate icon" type="image/png" href="../static.files/favicon-32x32-422f7d1d52889060.png"><link rel="icon" type="image/svg+xml" href="../static.files/favicon-2c020d218678b618.svg"></head><body class="rustdoc fn"><!--[if lte IE 11]><div class="warning">This old browser is unsupported and will most likely display funky things.</div><![endif]--><nav class="mobile-topbar"><button class="sidebar-menu-toggle">☰</button><a class="logo-container" href="../atomic_polyfill/index.html"><img class="rust-logo" src="../static.files/rust-logo-151179464ae7ed46.svg" alt="logo"></a><h2></h2></nav><nav class="sidebar"><a class="logo-container" href="../atomic_polyfill/index.html"><img class="rust-logo" src="../static.files/rust-logo-151179464ae7ed46.svg" alt="logo"></a><div class="sidebar-elems"><h2><a href="index.html">In atomic_polyfill</a></h2></div></nav><main><div class="width-limiter"><nav class="sub"><form class="search-form"><span></span><input class="search-input" name="search" aria-label="Run search in the documentation" autocomplete="off" spellcheck="false" placeholder="Click or press ‘S’ to search, ‘?’ for more options…" type="search"><div id="help-button" title="help" tabindex="-1"><a href="../help.html">?</a></div><div id="settings-menu" tabindex="-1"><a href="../settings.html" title="settings"><img width="22" height="22" alt="Change settings" src="../static.files/wheel-7b819b6101059cd0.svg"></a></div></form></nav><section id="main-content" class="content"><div class="main-heading"><h1>Function <a href="index.html">atomic_polyfill</a>::<wbr><a class="fn" href="#">compiler_fence</a><button id="copy-path" title="Copy item path to clipboard"><img src="../static.files/clipboard-7571035ce49a181d.svg" width="19" height="18" alt="Copy item path"></button></h1><span class="out-of-band"><span class="since" title="Stable since Rust version 1.21.0">1.21.0</span> · <button id="toggle-all-docs" title="collapse all docs">[<span>−</span>]</button></span></div><pre class="rust item-decl"><code>pub fn compiler_fence(order: <a class="enum" href="enum.Ordering.html" title="enum atomic_polyfill::Ordering">Ordering</a>)</code></pre><details class="toggle top-doc" open><summary class="hideme"><span>Expand description</span></summary><div class="docblock"><p>A compiler memory fence.</p>
|
||||
<p><code>compiler_fence</code> does not emit any machine code, but restricts the kinds
|
||||
of memory re-ordering the compiler is allowed to do. Specifically, depending on
|
||||
the given <a href="enum.Ordering.html" title="enum atomic_polyfill::Ordering"><code>Ordering</code></a> semantics, the compiler may be disallowed from moving reads
|
||||
or writes from before or after the call to the other side of the call to
|
||||
<code>compiler_fence</code>. Note that it does <strong>not</strong> prevent the <em>hardware</em>
|
||||
from doing such re-ordering. This is not a problem in a single-threaded,
|
||||
execution context, but when other threads may modify memory at the same
|
||||
time, stronger synchronization primitives such as <a href="fn.fence.html" title="fn atomic_polyfill::fence"><code>fence</code></a> are required.</p>
|
||||
<p>The re-ordering prevented by the different ordering semantics are:</p>
|
||||
<ul>
|
||||
<li>with <a href="enum.Ordering.html#variant.SeqCst" title="variant atomic_polyfill::Ordering::SeqCst"><code>SeqCst</code></a>, no re-ordering of reads and writes across this point is allowed.</li>
|
||||
<li>with <a href="enum.Ordering.html#variant.Release" title="variant atomic_polyfill::Ordering::Release"><code>Release</code></a>, preceding reads and writes cannot be moved past subsequent writes.</li>
|
||||
<li>with <a href="enum.Ordering.html#variant.Acquire" title="variant atomic_polyfill::Ordering::Acquire"><code>Acquire</code></a>, subsequent reads and writes cannot be moved ahead of preceding reads.</li>
|
||||
<li>with <a href="enum.Ordering.html#variant.AcqRel" title="variant atomic_polyfill::Ordering::AcqRel"><code>AcqRel</code></a>, both of the above rules are enforced.</li>
|
||||
</ul>
|
||||
<p><code>compiler_fence</code> is generally only useful for preventing a thread from
|
||||
racing <em>with itself</em>. That is, if a given thread is executing one piece
|
||||
of code, and is then interrupted, and starts executing code elsewhere
|
||||
(while still in the same thread, and conceptually still on the same
|
||||
core). In traditional programs, this can only occur when a signal
|
||||
handler is registered. In more low-level code, such situations can also
|
||||
arise when handling interrupts, when implementing green threads with
|
||||
pre-emption, etc. Curious readers are encouraged to read the Linux kernel’s
|
||||
discussion of <a href="https://www.kernel.org/doc/Documentation/memory-barriers.txt">memory barriers</a>.</p>
|
||||
<h2 id="panics"><a href="#panics">Panics</a></h2>
|
||||
<p>Panics if <code>order</code> is <a href="enum.Ordering.html#variant.Relaxed" title="variant atomic_polyfill::Ordering::Relaxed"><code>Relaxed</code></a>.</p>
|
||||
<h2 id="examples"><a href="#examples">Examples</a></h2>
|
||||
<p>Without <code>compiler_fence</code>, the <code>assert_eq!</code> in following code
|
||||
is <em>not</em> guaranteed to succeed, despite everything happening in a single thread.
|
||||
To see why, remember that the compiler is free to swap the stores to
|
||||
<code>IMPORTANT_VARIABLE</code> and <code>IS_READY</code> since they are both
|
||||
<code>Ordering::Relaxed</code>. If it does, and the signal handler is invoked right
|
||||
after <code>IS_READY</code> is updated, then the signal handler will see
|
||||
<code>IS_READY=1</code>, but <code>IMPORTANT_VARIABLE=0</code>.
|
||||
Using a <code>compiler_fence</code> remedies this situation.</p>
|
||||
|
||||
<div class="example-wrap"><pre class="rust rust-example-rendered"><code><span class="kw">use </span>std::sync::atomic::{AtomicBool, AtomicUsize};
|
||||
<span class="kw">use </span>std::sync::atomic::Ordering;
|
||||
<span class="kw">use </span>std::sync::atomic::compiler_fence;
|
||||
|
||||
<span class="kw">static </span>IMPORTANT_VARIABLE: AtomicUsize = AtomicUsize::new(<span class="number">0</span>);
|
||||
<span class="kw">static </span>IS_READY: AtomicBool = AtomicBool::new(<span class="bool-val">false</span>);
|
||||
|
||||
<span class="kw">fn </span>main() {
|
||||
IMPORTANT_VARIABLE.store(<span class="number">42</span>, Ordering::Relaxed);
|
||||
<span class="comment">// prevent earlier writes from being moved beyond this point
|
||||
</span>compiler_fence(Ordering::Release);
|
||||
IS_READY.store(<span class="bool-val">true</span>, Ordering::Relaxed);
|
||||
}
|
||||
|
||||
<span class="kw">fn </span>signal_handler() {
|
||||
<span class="kw">if </span>IS_READY.load(Ordering::Relaxed) {
|
||||
<span class="macro">assert_eq!</span>(IMPORTANT_VARIABLE.load(Ordering::Relaxed), <span class="number">42</span>);
|
||||
}
|
||||
}</code></pre></div>
|
||||
</div></details></section></div></main></body></html>
|
||||
Loading…
Add table
Add a link
Reference in a new issue