mirror of
https://github.com/mainmatter/100-exercises-to-learn-rust
synced 2024-12-24 21:58:13 +01:00
Clarify Send-Sync relationship (#237)
This commit is contained in:
parent
cc0092b2c6
commit
fb19005d5f
1 changed files with 5 additions and 5 deletions
|
@ -5,20 +5,20 @@ Before we wrap up this chapter, let's talk about another key trait in Rust's sta
|
|||
`Sync` is an auto trait, just like `Send`.\
|
||||
It is automatically implemented by all types that can be safely **shared** between threads.
|
||||
|
||||
In order words: `T: Sync` means that `&T` is `Send`.
|
||||
In order words: `T` is Sync if `&T` is `Send`.
|
||||
|
||||
## `Sync` doesn't imply `Send`
|
||||
## `T: Sync` doesn't imply `T: Send`
|
||||
|
||||
It's important to note that `Sync` doesn't imply `Send`.\
|
||||
It's important to note that `T` can be `Sync` without being `Send`.\
|
||||
For example: `MutexGuard` is not `Send`, but it is `Sync`.
|
||||
|
||||
It isn't `Send` because the lock must be released on the same thread that acquired it, therefore we don't
|
||||
want `MutexGuard` to be dropped on a different thread.\
|
||||
But it is `Sync`, because giving a `&MutexGuard` to another thread has no impact on where the lock is released.
|
||||
|
||||
## `Send` doesn't imply `Sync`
|
||||
## `T: Send` doesn't imply `T: Sync`
|
||||
|
||||
The opposite is also true: `Send` doesn't imply `Sync`.\
|
||||
The opposite is also true: `T` can be `Send` without being `Sync`.\
|
||||
For example: `RefCell<T>` is `Send` (if `T` is `Send`), but it is not `Sync`.
|
||||
|
||||
`RefCell<T>` performs runtime borrow checking, but the counters it uses to track borrows are not thread-safe.
|
||||
|
|
Loading…
Reference in a new issue