fix(threads, smart pointers): Swap order of threads and smart pointers exercises

closes #1541

1 files changed, 61 insertions, 61 deletions

diff --git a/info.toml b/info.toml
index 2add5f0..3abb2f8 100644
--- a/info.toml
+++ b/info.toml
@@ -905,67 +905,6 @@ The fold method can be useful in the count_collection_iterator function.
 For a further challenge, consult the documentation for Iterator to find
 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
 
 [[exercises]]
@@ -1028,6 +967,67 @@ Check out https://doc.rust-lang.org/std/borrow/enum.Cow.html for documentation
 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
 
 [[exercises]]