Trait core::marker::Sync
[−]
[src]
pub unsafe trait Sync { }Types that can be safely shared between threads when aliased.
The precise definition is: a type T`Tis` is Sync`Syncif` if &T`&Tis thread-safe. In other words, there is no possibility of data races when passing` is
thread-safe. In other words, there is no possibility of data races
when passing &T`&T` references between threads.
As one would expect, primitive types like u8`u8and` and f64`f64are all` are all
Sync`Sync, and so are simple aggregate types containing them (like tuples, structs and enums). More instances of basic`, and so are simple aggregate types containing them (like
tuples, structs and enums). More instances of basic Sync`Synctypes include "immutable" types like` types
include "immutable" types like &T`&Tand those with simple inherited mutability, such as` and those with simple
inherited mutability, such as Box<T>`Box,`, Vec<T>`Vecand most other collection types. (Generic parameters need to be` and most other
collection types. (Generic parameters need to be Sync`Syncfor their container to be` for their
container to be Sync`Sync`.)
A somewhat surprising consequence of the definition is &mut T`&mut Tis` is
Sync`Sync(if` (if T`Tis` is Sync`Sync) even though it seems that it might provide unsynchronised mutation. The trick is a mutable reference stored in an aliasable reference (that is,`) even though it seems that it might
provide unsynchronised mutation. The trick is a mutable reference
stored in an aliasable reference (that is, & &mut T`& &mut T) becomes read-only, as if it were a`) becomes
read-only, as if it were a & &T`& &T`, hence there is no risk of a data
race.
Types that are not Sync`Syncare those that have "interior mutability" in a non-thread-safe way, such as` are those that have "interior
mutability" in a non-thread-safe way, such as Cell`Celland` and RefCell`RefCellin`
in std::cell`std::cell. These types allow for mutation of their contents even when in an immutable, aliasable slot, e.g. the contents of`. These types allow for mutation of their contents
even when in an immutable, aliasable slot, e.g. the contents of
&Cell<T>`&Cellcan be` can be .set`.set, and do not ensure data races are impossible, hence they cannot be`, and do not ensure data races are
impossible, hence they cannot be Sync`Sync. A higher level example of a non-`. A higher level example
of a non-Sync`Synctype is the reference counted pointer` type is the reference counted pointer
std::rc::Rc`std::rc::Rc, because any reference`, because any reference &Rc<T>`&Rc
For cases when one does need thread-safe interior mutability,
types like the atomics in std::sync`std::syncand` and Mutex`Mutex&` & RWLock`RWLockin the` in
the sync`synccrate do ensure that any mutation cannot cause data races. Hence these types are` crate do ensure that any mutation cannot cause data
races. Hence these types are Sync`Sync`.
Any types with interior mutability must also use the std::cell::UnsafeCell`std::cell::UnsafeCellwrapper around the value(s) which can be mutated when behind a`
wrapper around the value(s) which can be mutated when behind a &`&reference; not doing this is undefined behaviour (for example,`
reference; not doing this is undefined behaviour (for example,
transmute`transmute-ing from`-ing from &T`&Tto` to &mut T`&mut T` is illegal).
Implementors
impl<T: Sync + ?Sized> Sync for Unique<T>impl<T> Sync for *const Timpl<T> Sync for *mut Timpl Sync for AtomicBoolimpl Sync for AtomicIsizeimpl Sync for AtomicUsizeimpl<T> Sync for AtomicPtr<T>impl<T: ?Sized> Sync for UnsafeCell<T>impl<'a, T: Sync> Sync for Iter<'a, T>impl<'a, T: Sync> Sync for IterMut<'a, T>