about summary refs log tree commit diff
path: root/src/libcore/sync
AgeCommit message (Collapse)AuthorLines
2020-07-27mv std libs to library/mark-2799/+0
2020-06-30Deny unsafe ops in unsafe fns, part 6LeSeulArtichaut-1/+0
And final part!!!
2020-06-30Deny unsafe ops in unsafe fns, part 3LeSeulArtichaut-104/+150
2020-06-12Rollup merge of #73036 - alexcrichton:update-wasm-fence, r=Mark-SimulacrumDylan DPC-8/+0
std: Enable atomic.fence emission on wasm32 This commit removes the `#[cfg]` guards in `atomic::fence` on wasm targets. Since these guards were originally added the upstream wasm specification for threads gained an `atomic.fence` instruction, so LLVM no longer panics on these intrinsics. Although there aren't a ton of tests in-repo for this right now I've tested locally and all of these fences generate `atomic.fence` instructions in wasm. Closes #65687 Closes #72997
2020-06-06Only mention `u8` and not booleansPoliorcetics-1/+1
Co-authored-by: Amanieu d'Antras <amanieu@gmail.com>
2020-06-05std: Enable atomic.fence emission on wasm32Alex Crichton-8/+0
This commit removes the `#[cfg]` guards in `atomic::fence` on wasm targets. Since these guards were originally added the upstream wasm specification for threads gained an `atomic.fence` instruction, so LLVM no longer panics on these intrinsics. Although there aren't a ton of tests in-repo for this right now I've tested locally and all of these fences generate `atomic.fence` instructions in wasm. Closes #72997
2020-06-05Improve the new documentation to be more precise about the necessary ↵Alexis Bourget-67/+97
platform's capabilities
2020-06-04Add a **Note**: comment in documentation when the type/method/function is ↵Alexis Bourget-13/+70
not always available
2020-05-29Rollup merge of #72324 - Amanieu:atomic_minmax, r=dtolnayYuki Okushi-10/+2
Stabilize AtomicN::fetch_min and AtomicN::fetch_max Some architectures (ARMv8.1 LSE and RISC-V) have specific instructions for atomic min/max which the compiler can only generate through explicit instrinsics.
2020-05-18Stabilize AtomicN::fetch_min and AtomicN::fetch_maxAmanieu d'Antras-10/+2
2020-05-03Update src/libcore/sync/atomic.rsSteven Fackler-1/+1
Co-authored-by: Ralf Jung <post@ralfj.de>
2020-05-03Tweak and stabilize AtomicN::fetch_updateSteven Fackler-14/+10
2020-03-18Use copy bound in atomic operations to generate simpler MIRTomasz Miąsko-15/+15
2020-02-11Document stable versions of `f32` and `f64` intrinsicsLeSeulArtichaut-2/+2
Fix links
2020-01-16Add SAFETY comment for atomic examplePhoebe Bell-1/+3
2020-01-16Elaborate on SAFETY commentsPhoebe Bell-31/+33
2020-01-16Document unsafe blocks in core::{cell, str, sync}Phoebe Bell-2/+31
2020-01-05Add more nuanced advice about spin_loop_hintAleksey Kladov-2/+4
2020-01-02Remove wrong advice about spin locks from `spin_loop_hint` docsAleksey Kladov-10/+2
Using a pure spin lock for a critical section in a preemptable thread is always wrong, however short the critical section may be. The thread might be preempted, which will cause all other threads to hammer busily at the core for the whole quant. Moreover, if threads have different priorities, this might lead to a priority inversion problem and a deadlock. More generally, a spinlock is not more efficient than a well-written mutex, which typically does several spin iterations at the start anyway. The advise about UP vs SMP is also irrelevant in the context of preemptive threads.
2019-12-22Format the worldMark Rousskov-60/+76
2019-12-18Propagate cfg bootstrapMark Rousskov-3/+3
2019-12-15use Self alias in place of macrosLzu Tao-1/+1
2019-12-13The constness of 128 bit atomics will be stabilized together with the atomicsOliver Scherer-2/+2
2019-12-13Address review commentsOliver Scherer-65/+0
2019-12-13Require stable/unstable annotations for the constness of all stable ↵Oliver Scherer-0/+81
functions with a `const` modifier
2019-12-05Rollup merge of #67005 - andrewbanchich:master, r=joshtriplettMazdak Farrokhzad-1/+1
capitalize Rust Capitalize "Rust" in docs.
2019-12-03capitalize RustAndrew Banchich-1/+1
2019-11-30Rollup merge of #66705 - pitdicker:atomic_mut_ptr, r=KodrAusMazdak Farrokhzad-0/+74
Atomic as_mut_ptr I encountered the following pattern a few times: In Rust we use some atomic type like `AtomicI32`, and an FFI interface exposes this as `*mut i32` (or some similar `libc` type). It was not obvious to me if a just transmuting a pointer to the atomic was acceptable, or if this should use a cast that goes through an `UnsafeCell`. See https://github.com/rust-lang/rust/issues/66136#issuecomment-557802477 Transmuting the pointer directly: ```rust let atomic = AtomicI32::new(1); let ptr = &atomic as *const AtomicI32 as *mut i32; unsafe { ffi(ptr); } ``` A dance with `UnsafeCell`: ```rust let atomic = AtomicI32::new(1); unsafe { let ptr = (&*(&atomic as *const AtomicI32 as *const UnsafeCell<i32>)).get(); ffi(ptr); } ``` Maybe in the end both ways could be valid. But why not expose a direct method to get a pointer from the standard library? An `as_mut_ptr` method on atomics can be safe, because only the use of the resulting pointer is where things can get unsafe. I documented its use for FFI, and "Doing non-atomic reads and writes on the resulting integer can be a data race." The standard library could make use this method in a few places in the WASM module. cc @RalfJung as you answered my original question.
2019-11-30Fill tracking issuePaul Dicker-2/+2
2019-11-30Document why as_mut_ptr is safePaul Dicker-0/+12
2019-11-23Add as_mut_ptr method to atomic types.Paul Dicker-0/+62
2019-11-12Snap cfgsMark Rousskov-35/+29
2019-11-06Have tidy ensure that we document all `unsafe` blocks in libcoreOliver Scherer-0/+2
2019-10-13Rollup merge of #65214 - Amanieu:cfg_atomic, r=alexcrichtonMazdak Farrokhzad-70/+92
Split non-CAS atomic support off into target_has_atomic_load_store This PR implements my proposed changes in https://github.com/rust-lang/rust/issues/32976#issuecomment-518542029 by removing `target_has_atomic = "cas"` and splitting `target_has_atomic` into two separate `cfg`s: * `target_has_atomic = 8/16/32/64/128`: This indicates the largest width that the target can atomically CAS (which implies support for all atomic operations). * ` target_has_atomic_load_store = 8/16/32/64/128`: This indicates the largest width that the target can support loading or storing atomically (but may not support CAS). cc #32976 r? @alexcrichton
2019-10-12fix link targetsRalf Jung-12/+12
2019-10-12it's C++20Ralf Jung-7/+7
2019-10-12do not reference LLVM for our concurrency memory modelRalf Jung-25/+27
2019-10-08Split non-CAS atomic support off into target_has_atomic_load_storeAmanieu d'Antras-70/+92
2019-09-18Rollup merge of #64348 - arnohaase:pr_documentation_spin_loop_hint, ↵Tyler Mandry-12/+15
r=alexcrichton PR: documentation spin loop hint The documentation for 'spin loop hint' explains that yield is better if the lock holder is running on the same CPU. I suggest that 'CPU or core' would be clearer.
2019-09-18broken hyperlinks in documentationArno Haase-1/+1
2019-09-17newly phrased documentation for spin loop hintsArno Haase-12/+15
2019-09-10fixed linter errorArno Haase-7/+7
2019-09-10documentation for AtomicPtr CAS operationsArno Haase-4/+2
2019-09-10documentation enhancement for 'spin loop hint': replace 'CPU' with 'CPU or core'Arno Haase-3/+3
2019-06-04Remove unneeded feature attr from atomic integers doctestsLzu Tao-8/+8
2019-04-19libcore: deny more...Mazdak Farrokhzad-4/+4
2019-04-18libcore => 2018Taiki Endo-5/+5
2019-04-03Updated the documentation of core::hints::spin_loop and ↵Christian-7/+20
core::sync::spin_loop_hint
2019-03-02Bootstrap compiler update for 1.35 releaseMark Rousskov-12/+4
2019-02-21Destabilize fixed-width const defined atomic integersMahmut Bulut-1/+14
* With this PR 1.34.0 onwards const declarations of atomic integers will be unstable.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-19 21:48:40 +0000