From 3e6a8cfbdbe22266e7eb2f9680fe1bba045e2b6c Mon Sep 17 00:00:00 2001
From: richard jarram <rjarram@me.com>
Date: Wed, 26 May 2021 20:27:26 -0700
Subject: [PATCH] docs(exercises): Updated challenge instructions for
threads1.rs #closes 287
I've seen from a cursory glance on the repo that a lot of people
struggle with this problem set because of the ambiguity in the
instructions (See issues #287, #743, #567).
I'd like to recommend perhaps putting a TODO on the lines that need
changing to stop people from falling down rabbit holes and pursuing
completely different solution to the exercise that avoids the core
pedagogical content of the problem, which is an understanding of
how Arc is an atomic reference counting primitive that relies on
.lock() and .unwrap() to solve shared state concurrency problems
with the Mutex primitive.
I've also added comments in the instructions to highlight why it is that
the solution is solved when the program prints the counter to the screen
6 times, as this was unclear and was distracting students from the core
takeaway of the exercise.
---
exercises/threads/threads1.rs | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/exercises/threads/threads1.rs b/exercises/threads/threads1.rs
index f31b317..1adef48 100644
--- a/exercises/threads/threads1.rs
+++ b/exercises/threads/threads1.rs
@@ -4,7 +4,13 @@
// monitoring progress until 10 jobs are completed. Because of the difference between the
// spawned threads' sleep time, and the waiting threads sleep time, when you see 6 lines
// of "waiting..." and the program ends without timing out when running,
-// you've got it :)
+// you've got it :)
+// Why 6 lines, you ask? because the program will spawn one new thread that will increment
+// the Jobstatus on 250ms intervals. At the same time, our original thread will check
+// the Jobstatus at 500ms intervals. So, this count should be ~0 on the first iteration of
+// the `while` loop; ~2 on the second iteration; ~4 on the third iteration; finally,
+// ~10 on the sixth. Why? Because by the time our main thread peeks at the JobStatus counter,
+// our second spawned thread will have already run two incremental operations on it.
// I AM NOT DONE
@@ -17,14 +23,19 @@ struct JobStatus {
}
fn main() {
+ // TODO: Change the line below
let status = Arc::new(JobStatus { jobs_completed: 0 });
let status_shared = status.clone();
+ // The code below spawns a single new thread that will run a for-loop code block 10 times.
thread::spawn(move || {
for _ in 0..10 {
thread::sleep(Duration::from_millis(250));
+ // TODO: change the line below
status_shared.jobs_completed += 1;
}
});
+ // The code below will check the count on JobStatus on 500ms intervals.
+ // TODO: Change the line below
while status.jobs_completed < 10 {
println!("waiting... ");
thread::sleep(Duration::from_millis(500));