languages/rust
languages/rust
1
0
Fork 0
mirror of https://github.com/rust-lang/rust synced 2024-07-21 02:15:40 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Address @parched's comments

Browse source
This commit is contained in:
Jon Gjengset 2017-04-08 14:03:17 -04:00
parent e6597e12bc
commit f093d59c31
No known key found for this signature in database
GPG key ID: D64AC9D67176DC71
1 changed files with 3 additions and 8 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

11
src/doc/unstable-book/src/compiler-barriers.md
View file

@ -22,8 +22,9 @@ compiler is allowed to do. Specifically, depending on the given ordering
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
`compiler_barrier`. Note that it does **not** prevent the *hardware*
from doing such re-orderings -- for that, the `volatile_*` class of
functions, or full memory fences, need to be used.
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 are required.
## Examples
@ -92,12 +93,6 @@ fn signal_handler() {
}
```
In more advanced cases (for example, if `IMPORTANT_VARIABLE` was an
`AtomicPtr` that starts as `NULL`), it may also be unsafe for the
compiler to hoist code using `IMPORTANT_VARIABLE` above the
`IS_READY.load`. In that case, a `compiler_barrier(Ordering::Acquire)`
should be placed at the top of the `if` to prevent this optimizations.
A deeper discussion of compiler barriers with various re-ordering
semantics (such as `Ordering::SeqCst`) is beyond the scope of this text.
Curious readers are encouraged to read the Linux kernel's discussion of