From f74fbd48008bf3652a9068e6297a85eb6811d6a3 Mon Sep 17 00:00:00 2001
From: =?utf8?q?On=C3=A8?= <43485962+c-git@users.noreply.github.com>
Date: Tue, 28 May 2024 05:04:08 -0400
Subject: [PATCH] typos (#55)

* Add missing of

* change tense of spawn

* ignored to ignoring

* add need
---
 book/src/07_threads/00_intro.md            | 2 +-
 book/src/07_threads/11_locks.md            | 2 +-
 book/src/07_threads/13_without_channels.md | 2 +-
 exercises/07_threads/01_threads/src/lib.rs | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/book/src/07_threads/00_intro.md b/book/src/07_threads/00_intro.md
index 6d687ad..f3c4b1e 100644
--- a/book/src/07_threads/00_intro.md
+++ b/book/src/07_threads/00_intro.md
@@ -12,4 +12,4 @@ We'll have the opportunity to touch most of Rust's core concurrency features, in
 - Shared state, using `Arc`, `Mutex` and `RwLock`
 - `Send` and `Sync`, the traits that encode Rust's concurrency guarantees
 
-We'll also discuss various design patterns for multithreaded systems and some their trade-offs.
+We'll also discuss various design patterns for multithreaded systems and some of their trade-offs.
diff --git a/book/src/07_threads/11_locks.md b/book/src/07_threads/11_locks.md
index d079114..2cab7de 100644
--- a/book/src/07_threads/11_locks.md
+++ b/book/src/07_threads/11_locks.md
@@ -74,7 +74,7 @@ struct TicketStore {
 ```
 
 This approach is more efficient, but it has a downside: `TicketStore` has to become **aware** of the multithreaded
-nature of the system; up until now, `TicketStore` has been blissfully ignored the existence of threads.\
+nature of the system; up until now, `TicketStore` has been blissfully ignoring the existence of threads.\
 Let's go for it anyway.
 
 ## Who holds the lock?
diff --git a/book/src/07_threads/13_without_channels.md b/book/src/07_threads/13_without_channels.md
index bb018ee..0c5774a 100644
--- a/book/src/07_threads/13_without_channels.md
+++ b/book/src/07_threads/13_without_channels.md
@@ -48,7 +48,7 @@ If we remove the channels, we need to introduce (another) lock to synchronize ac
 
 If we use a `Mutex`, then it makes no sense to use an additional `RwLock` for each ticket: the `Mutex` will
 already serialize access to the entire store, so we wouldn't be able to read tickets in parallel anyway.\
-If we use a `RwLock`, instead, we can read tickets in parallel. We just to pause all reads while inserting
+If we use a `RwLock`, instead, we can read tickets in parallel. We just need to pause all reads while inserting
 or removing a ticket.
 
 Let's go down this path and see where it leads us.
diff --git a/exercises/07_threads/01_threads/src/lib.rs b/exercises/07_threads/01_threads/src/lib.rs
index 946cc9a..7d084ac 100644
--- a/exercises/07_threads/01_threads/src/lib.rs
+++ b/exercises/07_threads/01_threads/src/lib.rs
@@ -8,7 +8,7 @@
 // You _could_ pass this test by just returning `v.iter().sum()`,
 // but that would defeat the purpose of the exercise.
 //
-// Hint: you won't be able to get the spawn threads to _borrow_
+// Hint: you won't be able to get the spawned threads to _borrow_
 // slices of the vector directly. You'll need to allocate new
 // vectors for each half of the original vector. We'll see why
 // this is necessary in the next exercise.
-- 
2.45.2