Compare commits
3 Commits
bd9faa049f
...
5140cd3b37
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
5140cd3b37 | ||
|
|
3020ef6c3f | ||
|
|
f74fbd4800 |
@@ -51,7 +51,7 @@ let y = point.1;
|
|||||||
|
|
||||||
### Tuples
|
### Tuples
|
||||||
|
|
||||||
It's weird say that something is tuple-like when we haven't seen tuples yet!\
|
It's weird to say that something is tuple-like when we haven't seen tuples yet!\
|
||||||
Tuples are another example of a primitive Rust type.
|
Tuples are another example of a primitive Rust type.
|
||||||
They group together a fixed number of values with (potentially different) types:
|
They group together a fixed number of values with (potentially different) types:
|
||||||
|
|
||||||
|
|||||||
@@ -2,7 +2,7 @@
|
|||||||
|
|
||||||
## Error reporting
|
## Error reporting
|
||||||
|
|
||||||
In the previous exercise you had to destructure the `InvalidTitle` variant to extract the error message and
|
In the previous exercise you had to destructure the `TitleError` variant to extract the error message and
|
||||||
pass it to the `panic!` macro.\
|
pass it to the `panic!` macro.\
|
||||||
This is a (rudimentary) example of **error reporting**: transforming an error type into a representation that can be
|
This is a (rudimentary) example of **error reporting**: transforming an error type into a representation that can be
|
||||||
shown to a user, a service operator, or a developer.
|
shown to a user, a service operator, or a developer.
|
||||||
|
|||||||
@@ -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.
|
||||||
|
|||||||
@@ -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?
|
||||||
|
|||||||
@@ -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.
|
||||||
|
|||||||
@@ -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.
|
||||||
|
|||||||
Reference in New Issue
Block a user