Miroirs/100-exercises-to-learn-rust
1
0
Fork 0
mirror of https://github.com/mainmatter/100-exercises-to-learn-rust synced 2024-12-26 21:58:49 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions

typos (#55)

Browse source 
* Add missing of

* change tense of spawn

* ignored to ignoring

* add need
This commit is contained in:
Onè 2024-05-28 05:04:08 -04:00 committed by GitHub
parent bd9faa049f
commit f74fbd4800
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
4 changed files with 4 additions and 4 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
book/src/07_threads/00_intro.md
View file

@ -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` - Shared state, using `Arc`, `Mutex` and `RwLock`
- `Send` and `Sync`, the traits that encode Rust's concurrency guarantees - `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
book/src/07_threads/11_locks.md
View file

@ -74,7 +74,7 @@ struct TicketStore {
``` ```
This approach is more efficient, but it has a downside: `TicketStore` has to become **aware** of the multithreaded 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. Let's go for it anyway.
## Who holds the lock? ## Who holds the lock?

2
book/src/07_threads/13_without_channels.md
View file

@ -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 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.\ 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. or removing a ticket.
Let's go down this path and see where it leads us. Let's go down this path and see where it leads us.

2
exercises/07_threads/01_threads/src/lib.rs
View file

@ -8,7 +8,7 @@
// You _could_ pass this test by just returning `v.iter().sum()`, // You _could_ pass this test by just returning `v.iter().sum()`,
// but that would defeat the purpose of the exercise. // 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 // slices of the vector directly. You'll need to allocate new
// vectors for each half of the original vector. We'll see why // vectors for each half of the original vector. We'll see why
// this is necessary in the next exercise. // this is necessary in the next exercise.