Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

typos #55

Merged
merged 4 commits into from
May 28, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion book/src/07_threads/00_intro.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.
2 changes: 1 addition & 1 deletion book/src/07_threads/11_locks.md
Original file line number Diff line number Diff line change
Expand Up @@ -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?
Expand Down
2 changes: 1 addition & 1 deletion book/src/07_threads/13_without_channels.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.
2 changes: 1 addition & 1 deletion exercises/07_threads/01_threads/src/lib.rs
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Expand Down
Loading