Clarify Send-Sync relationship (#237)

Author: LukeMathWalker

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<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.