From fb19005d5fbda39bcd8619ec91bb5c1621d414d1 Mon Sep 17 00:00:00 2001 From: Luca Palmieri <20745048+LukeMathWalker@users.noreply.github.com> Date: Wed, 18 Dec 2024 17:22:16 +0100 Subject: [PATCH] Clarify Send-Sync relationship (#237) --- book/src/07_threads/14_sync.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/book/src/07_threads/14_sync.md b/book/src/07_threads/14_sync.md index 32ac465da..2dc7d3f5b 100644 --- a/book/src/07_threads/14_sync.md +++ b/book/src/07_threads/14_sync.md @@ -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` is `Send` (if `T` is `Send`), but it is not `Sync`. `RefCell` performs runtime borrow checking, but the counters it uses to track borrows are not thread-safe.