From b0275ab6fd268e470114216f8b0b83481814c713 Mon Sep 17 00:00:00 2001 From: Bulat Musin Date: Tue, 9 Jan 2018 07:51:20 +0300 Subject: [PATCH] fix typo, put quotes around Rc --- src/send-and-sync.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/src/send-and-sync.md b/src/send-and-sync.md index ecc4e53..d11b118 100644 --- a/src/send-and-sync.md +++ b/src/send-and-sync.md @@ -2,7 +2,7 @@ Not everything obeys inherited mutability, though. Some types allow you to have multiple aliases of a location in memory while mutating it. Unless these types use -synchronization to manage this access, they are absolutely not thread safe. Rust +synchronization to manage this access, they are absolutely not thread-safe. Rust captures this through the `Send` and `Sync` traits. * A type is Send if it is safe to send it to another thread. @@ -35,11 +35,11 @@ with a raw pointer requires dereferencing it, which is already unsafe. In that sense, one could argue that it would be "fine" for them to be marked as thread safe. -However it's important that they aren't thread safe to prevent types that -contain them from being automatically marked as thread safe. These types have +However it's important that they aren't thread-safe to prevent types that +contain them from being automatically marked as thread-safe. These types have non-trivial untracked ownership, and it's unlikely that their author was -necessarily thinking hard about thread safety. In the case of Rc, we have a nice -example of a type that contains a `*mut` that is definitely not thread safe. +necessarily thinking hard about thread safety. In the case of `Rc`, we have a nice +example of a type that contains a `*mut` that is definitely not thread-safe. Types that aren't automatically derived can simply implement them if desired: