Skip to content

Commit

Permalink
Merge pull request #1929 from mo8it/threads2
Browse files Browse the repository at this point in the history
threads2: simplify the exercise
  • Loading branch information
shadows-withal committed Mar 31, 2024
2 parents 4e59857 + 842e341 commit ca07abf
Show file tree
Hide file tree
Showing 2 changed files with 13 additions and 18 deletions.
11 changes: 7 additions & 4 deletions exercises/20_threads/threads2.rs
Expand Up @@ -18,7 +18,9 @@ struct JobStatus {
}

fn main() {
// TODO: `Arc` isn't enough if you want a **mutable** shared state
let status = Arc::new(JobStatus { jobs_completed: 0 });

let mut handles = vec![];
for _ in 0..10 {
let status_shared = Arc::clone(&status);
Expand All @@ -29,11 +31,12 @@ fn main() {
});
handles.push(handle);
}

// Waiting for all jobs to complete
for handle in handles {
handle.join().unwrap();
// TODO: Print the value of the JobStatus.jobs_completed. Did you notice
// anything interesting in the output? Do you have to 'join' on all the
// handles?
println!("jobs completed {}", ???);
}

// TODO: Print the value of `JobStatus.jobs_completed`
println!("Jobs completed: {}", ???);
}
20 changes: 6 additions & 14 deletions info.toml
Expand Up @@ -1136,25 +1136,17 @@ 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:
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 'Sharing a Mutex<T> Between Multiple Threads'. 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 :)"""
Similar to the code in the following example in the book:
https://doc.rust-lang.org/book/ch16-03-shared-state.html#sharing-a-mutext-between-multiple-threads
"""

[[exercises]]
name = "threads3"
Expand Down

0 comments on commit ca07abf

Please sign in to comment.