pub unsafe auto trait Sync { }Expand description
Types for which it is safe to share references between threads.
This trait is automatically implemented when the compiler determines it’s appropriate.
The precise definition is: a type T is Sync if and only if &T is
Send. In other words, if there is no possibility of
undefined behavior (including data races) when passing
&T references between threads.
As one would expect, primitive types like u8 and f64
are all Sync, and so are simple aggregate types containing them,
like tuples, structs and enums. More examples of basic Sync
types include “immutable” types like &T, and those with simple
inherited mutability, such as Box<T>, Vec<T> and
most other collection types. (Generic parameters need to be Sync
for their container to be Sync.)
A somewhat surprising consequence of the definition is that &mut T
is Sync (if T is Sync) even though it seems like that might
provide unsynchronized mutation. The trick is that a mutable
reference behind a shared reference (that is, & &mut T)
becomes read-only, as if it were a & &T. Hence there is no risk
of a data race.
Types that are not Sync are those that have “interior
mutability” in a non-thread-safe form, such as Cell
and RefCell. These types allow for mutation of
their contents even through an immutable, shared reference. For
example the set method on Cell<T> takes &self, so it requires
only a shared reference &Cell<T>. The method performs no
synchronization, thus Cell cannot be Sync.
Another example of a non-Sync type is the reference-counting
pointer Rc. Given any reference &Rc<T>, you can clone
a new Rc<T>, modifying the reference counts in a non-atomic way.
For cases when one does need thread-safe interior mutability,
Rust provides atomic data types, as well as explicit locking via
sync::Mutex and sync::RwLock. These types
ensure that any mutation cannot cause data races, hence the types
are Sync. Likewise, sync::Arc provides a thread-safe
analogue of Rc.
Any types with interior mutability must also use the
cell::UnsafeCell wrapper around the value(s) which
can be mutated through a shared reference. Failing to doing this is
undefined behavior. For example, transmute-ing
from &T to &mut T is invalid.
See the Nomicon for more details about Sync.
Implementations on Foreign Types
impl Sync for Argument
impl Sync for FormatSpec
impl Sync for Alignment
impl Sync for Count
NonNull pointers are not Sync because the data they reference may be aliased.
Conditionally mark BitSlice as Sync based on its T type argument.
In order for BitSlice to be Sync (that is, &BitSlice can be copied across
thread boundaries), it must be capable of reading from memory without being
invalidated by any other &mut BitSlice handles that alias the same memory
address.
This is true when T is one of the fundamental integers, because no other
&mut BitSlice handle can exist to effect mutations, or when T is a BitSafe
type that implements atomic read-modify-write instructions, because it will
guard against other &mut BitSlice modifications in hardware.
When T is a non-atomic BitSafe type, BitSlice cannot be Sync, because
one &BitSlice moved across a thread boundary may read from memory that is
modified by the originally-owning thread, but the instructions used to access
memory do not guard against such data races.
A &BitSlice over aliased memory addresses is equivalent to either a &Cell
or &AtomicT, depending on what the radium crate makes available for the
register width.