mirror of
https://github.com/mainmatter/100-exercises-to-learn-rust
synced 2024-12-25 21:58:26 +01:00
typos (#55)
* Add missing of * change tense of spawn * ignored to ignoring * add need
This commit is contained in:
parent
bd9faa049f
commit
f74fbd4800
4 changed files with 4 additions and 4 deletions
|
@ -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.
|
||||
|
|
|
@ -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?
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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.
|
||||
|
|
Loading…
Reference in a new issue