Why does variable binding affect lifetime inside a loop body? - multithreading

Question

In "The Rust Programming Language" in chapter 20 you go through an exercise of building a simple multi-threaded web server. In the exercise you use a single std::sync::mpsc channel. The worker threads all access a single Receiver which is contained like: Arc<Mutex<mpsc::Receiver<Message>>>.
If we write the worker thread like:
let thread = thread::spawn(move || loop {
match receiver.lock().unwrap().recv().unwrap() {
Message::NewJob(job) => {
println!("Worker {} got a job; executing.", id);
job.call_box();
println!("Worker {} job complete.", id);
}
Message::Terminate => {
println!("Worker {} was told to terminate.", id);
break;
}
};
println!("hello, loop");
});
Then we do not achieve concurrency, apparently the worker holds on to the mutex lock I supposed because no worker is able to pull off another job until the previous one is complete. However if we simply change it to this (how the book shows the code):
let thread = thread::spawn(move || loop {
let message = receiver.lock().unwrap().recv().unwrap();
match message {
Message::NewJob(job) => {
println!("Worker {} got a job; executing.", id);
job.call_box();
println!("Worker {} job complete.", id);
}
Message::Terminate => {
println!("Worker {} was told to terminate.", id);
break;
}
};
println!("hello, loop");
});
Then everything works fine. If you fire off 5 requests you'll see each thread gets one immediately. Concurrency!
The question is "why does variable binding affect lifetime" (I'm assuming that's the reason). Or if not then I'm missing something and what is that?! The book itself talks about how you cannot implement the worker loop with while let Ok(job) = receiver.lock().unwrap().recv() { because of the scope of the lock but apparently even inside the loop there be dragons.

Answer 1

Because in Rust, "resource acquisition is initialization".
Specifically receiver.lock() returns a type which acquires the lock when it is initialized and releases the lock when it is dropped.
In your first example, the lifetime of the MutexGuard extends to the end of the match statement, so the lock will be held while job.call_box() is called.
match receiver.lock().unwrap().recv().unwrap() {
// ...
};
// `MutexGuard` is dropped and lock is released here
In your second example, the lock guard is only kept alive long enough to read a message from your message queue; the lock guard is dropped at the end of the statement and the lock is released before the match is entered.
let message = receiver.lock().unwrap().recv().unwrap();
// `MutexGuard` is dropped and lock is released here
match message {