mirror of
https://github.com/notohh/rustlings.git
synced 2024-11-22 14:02:22 -05:00
Merge pull request #1542 from luhem7/main
fix(threads, smart pointers): Swap order of threads and smart pointers exercises
This commit is contained in:
commit
44f706a5e7
1 changed files with 61 additions and 61 deletions
122
info.toml
122
info.toml
|
@ -906,67 +906,6 @@ The fold method can be useful in the count_collection_iterator function.
|
||||||
For a further challenge, consult the documentation for Iterator to find
|
For a further challenge, consult the documentation for Iterator to find
|
||||||
a different method that could make your code more compact than using fold."""
|
a different method that could make your code more compact than using fold."""
|
||||||
|
|
||||||
# THREADS
|
|
||||||
|
|
||||||
[[exercises]]
|
|
||||||
name = "threads1"
|
|
||||||
path = "exercises/threads/threads1.rs"
|
|
||||||
mode = "compile"
|
|
||||||
hint = """
|
|
||||||
`JoinHandle` is a struct that is returned from a spawned thread:
|
|
||||||
https://doc.rust-lang.org/std/thread/fn.spawn.html
|
|
||||||
|
|
||||||
A challenge with multi-threaded applications is that the main thread can
|
|
||||||
finish before the spawned threads are completed.
|
|
||||||
https://doc.rust-lang.org/book/ch16-01-threads.html#waiting-for-all-threads-to-finish-using-join-handles
|
|
||||||
|
|
||||||
Use the JoinHandles to wait for each thread to finish and collect their results.
|
|
||||||
https://doc.rust-lang.org/std/thread/struct.JoinHandle.html
|
|
||||||
"""
|
|
||||||
|
|
||||||
[[exercises]]
|
|
||||||
name = "threads2"
|
|
||||||
path = "exercises/threads/threads2.rs"
|
|
||||||
mode = "compile"
|
|
||||||
hint = """
|
|
||||||
`Arc` is an Atomic Reference Counted pointer that allows safe, shared access
|
|
||||||
to **immutable** data. But we want to *change* the number of `jobs_completed`
|
|
||||||
so we'll need to also use another type that will only allow one thread to
|
|
||||||
mutate the data at a time. Take a look at this section of the book:
|
|
||||||
https://doc.rust-lang.org/book/ch16-03-shared-state.html#atomic-reference-counting-with-arct
|
|
||||||
and keep reading if you'd like more hints :)
|
|
||||||
|
|
||||||
|
|
||||||
Do you now have an `Arc` `Mutex` `JobStatus` at the beginning of main? Like:
|
|
||||||
`let status = Arc::new(Mutex::new(JobStatus { jobs_completed: 0 }));`
|
|
||||||
Similar to the code in the example in the book that happens after the text
|
|
||||||
that says "We can use Arc<T> to fix this.". If not, give that a try! If you
|
|
||||||
do and would like more hints, keep reading!!
|
|
||||||
|
|
||||||
|
|
||||||
Make sure neither of your threads are holding onto the lock of the mutex
|
|
||||||
while they are sleeping, since this will prevent the other thread from
|
|
||||||
being allowed to get the lock. Locks are automatically released when
|
|
||||||
they go out of scope.
|
|
||||||
|
|
||||||
If you've learned from the sample solutions, I encourage you to come
|
|
||||||
back to this exercise and try it again in a few days to reinforce
|
|
||||||
what you've learned :)"""
|
|
||||||
|
|
||||||
[[exercises]]
|
|
||||||
name = "threads3"
|
|
||||||
path = "exercises/threads/threads3.rs"
|
|
||||||
mode = "compile"
|
|
||||||
hint = """
|
|
||||||
An alternate way to handle concurrency between threads is to use
|
|
||||||
a mpsc (multiple producer, single consumer) channel to communicate.
|
|
||||||
With both a sending end and a receiving end, it's possible to
|
|
||||||
send values in one thread and receive them in another.
|
|
||||||
Multiple producers are possible by using clone() to create a duplicate
|
|
||||||
of the original sending end.
|
|
||||||
See https://doc.rust-lang.org/book/ch16-02-message-passing.html for more info.
|
|
||||||
"""
|
|
||||||
|
|
||||||
# SMART POINTERS
|
# SMART POINTERS
|
||||||
|
|
||||||
[[exercises]]
|
[[exercises]]
|
||||||
|
@ -1029,6 +968,67 @@ Check out https://doc.rust-lang.org/std/borrow/enum.Cow.html for documentation
|
||||||
on the `Cow` type.
|
on the `Cow` type.
|
||||||
"""
|
"""
|
||||||
|
|
||||||
|
# THREADS
|
||||||
|
|
||||||
|
[[exercises]]
|
||||||
|
name = "threads1"
|
||||||
|
path = "exercises/threads/threads1.rs"
|
||||||
|
mode = "compile"
|
||||||
|
hint = """
|
||||||
|
`JoinHandle` is a struct that is returned from a spawned thread:
|
||||||
|
https://doc.rust-lang.org/std/thread/fn.spawn.html
|
||||||
|
|
||||||
|
A challenge with multi-threaded applications is that the main thread can
|
||||||
|
finish before the spawned threads are completed.
|
||||||
|
https://doc.rust-lang.org/book/ch16-01-threads.html#waiting-for-all-threads-to-finish-using-join-handles
|
||||||
|
|
||||||
|
Use the JoinHandles to wait for each thread to finish and collect their results.
|
||||||
|
https://doc.rust-lang.org/std/thread/struct.JoinHandle.html
|
||||||
|
"""
|
||||||
|
|
||||||
|
[[exercises]]
|
||||||
|
name = "threads2"
|
||||||
|
path = "exercises/threads/threads2.rs"
|
||||||
|
mode = "compile"
|
||||||
|
hint = """
|
||||||
|
`Arc` is an Atomic Reference Counted pointer that allows safe, shared access
|
||||||
|
to **immutable** data. But we want to *change* the number of `jobs_completed`
|
||||||
|
so we'll need to also use another type that will only allow one thread to
|
||||||
|
mutate the data at a time. Take a look at this section of the book:
|
||||||
|
https://doc.rust-lang.org/book/ch16-03-shared-state.html#atomic-reference-counting-with-arct
|
||||||
|
and keep reading if you'd like more hints :)
|
||||||
|
|
||||||
|
|
||||||
|
Do you now have an `Arc` `Mutex` `JobStatus` at the beginning of main? Like:
|
||||||
|
`let status = Arc::new(Mutex::new(JobStatus { jobs_completed: 0 }));`
|
||||||
|
Similar to the code in the example in the book that happens after the text
|
||||||
|
that says "We can use Arc<T> to fix this.". If not, give that a try! If you
|
||||||
|
do and would like more hints, keep reading!!
|
||||||
|
|
||||||
|
|
||||||
|
Make sure neither of your threads are holding onto the lock of the mutex
|
||||||
|
while they are sleeping, since this will prevent the other thread from
|
||||||
|
being allowed to get the lock. Locks are automatically released when
|
||||||
|
they go out of scope.
|
||||||
|
|
||||||
|
If you've learned from the sample solutions, I encourage you to come
|
||||||
|
back to this exercise and try it again in a few days to reinforce
|
||||||
|
what you've learned :)"""
|
||||||
|
|
||||||
|
[[exercises]]
|
||||||
|
name = "threads3"
|
||||||
|
path = "exercises/threads/threads3.rs"
|
||||||
|
mode = "compile"
|
||||||
|
hint = """
|
||||||
|
An alternate way to handle concurrency between threads is to use
|
||||||
|
a mpsc (multiple producer, single consumer) channel to communicate.
|
||||||
|
With both a sending end and a receiving end, it's possible to
|
||||||
|
send values in one thread and receive them in another.
|
||||||
|
Multiple producers are possible by using clone() to create a duplicate
|
||||||
|
of the original sending end.
|
||||||
|
See https://doc.rust-lang.org/book/ch16-02-message-passing.html for more info.
|
||||||
|
"""
|
||||||
|
|
||||||
# MACROS
|
# MACROS
|
||||||
|
|
||||||
[[exercises]]
|
[[exercises]]
|
||||||
|
|
Loading…
Reference in a new issue