Sync in std::marker - Rust (original) (raw)
Trait Sync
1.0.0 · Source
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 isSend. In other words, if there is no possibility ofundefined behavior (including data races) when passing&T references between threads.
As one would expect, primitive types like u8 and f64are all Sync, and so are simple aggregate types containing them, like tuples, structs and enums. More examples of basic Synctypes include “immutable” types like &T, and those with simple inherited mutability, such as Box, Vec and most other collection types. (Generic parameters need to be Syncfor their container to be Sync.)
A somewhat surprising consequence of the definition is that &mut Tis 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.
A shorter overview of how Sync and Send relate to referencing:
&Tis Send if and only ifTis Sync&mut Tis Send if and only ifTis Send&Tand&mut Tare Sync if and only ifTis Sync
Types that are not Sync are those that have “interior mutability” in a non-thread-safe form, such as Celland RefCell. These types allow for mutation of their contents even through an immutable, shared reference. For example the set method on Cell takes &self, so it requires only a shared reference &Cell. 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, you can clone a new Rc, 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 viasync::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 thecell::UnsafeCell wrapper around the value(s) which can be mutated through a shared reference. Failing to doing this isundefined behavior. For example, transmute-ing from &T to &mut T is invalid.
See the Nomicon for more details about Sync.
NonNull pointers are not Sync because the data they reference may be aliased.
Available on Windows only.
Available on Windows only.
Available on Windows only.
Available on Windows only.
Available on target_has_atomic_load_store=8 only.
ThinBox<T> is Sync if T is Sync because the data is owned.
Available on target_has_atomic_load_store=ptr only.
T must be Send for Mutex to be Sync. This ensures that the protected data can be accessed safely from multiple threads without causing data races or other unsafe behavior.
Mutex provides mutable access to T to one thread at a time. However, it’s essential for T to be Send because it’s not safe for non-Send structures to be accessed in this manner. For instance, consider Rc, a non-atomic reference counted smart pointer, which is not Send. With Rc, we can have multiple copies pointing to the same heap allocation with a non-atomic reference count. If we were to use Mutex<Rc<_>>, it would only protect one instance of Rc from shared access, leaving other copies vulnerable to potential data races.
Also note that it is not necessary for T to be Sync as &T is only made available to one thread at a time if T is not Sync.
T must be Send for Mutex to be Sync. This ensures that the protected data can be accessed safely from multiple threads without causing data races or other unsafe behavior.
Mutex provides mutable access to T to one thread at a time. However, it’s essential for T to be Send because it’s not safe for non-Send structures to be accessed in this manner. For instance, consider Rc, a non-atomic reference counted smart pointer, which is not Send. With Rc, we can have multiple copies pointing to the same heap allocation with a non-atomic reference count. If we were to use Mutex<Rc<_>>, it would only protect one instance of Rc from shared access, leaving other copies vulnerable to potential data races.
Also note that it is not necessary for T to be Sync as &T is only made available to one thread at a time if T is not Sync.
T must be Sync for a MutexGuard to be Syncbecause it is possible to get a &T from &MutexGuard (via Deref).
T must be Sync for a MutexGuard to be Syncbecause it is possible to get a &T from &MutexGuard (via Deref).