From ca2056ec9981a530cbc6a5c0d897d052d05be745 Mon Sep 17 00:00:00 2001 From: "Carol (Nichols || Goulding)" Date: Sun, 1 May 2022 20:14:55 -0400 Subject: [PATCH] Clarify sentences about lock types. Fixes #2937. --- src/ch16-03-shared-state.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/src/ch16-03-shared-state.md b/src/ch16-03-shared-state.md index 19f1e8decd..6c46555ddf 100644 --- a/src/ch16-03-shared-state.md +++ b/src/ch16-03-shared-state.md @@ -71,9 +71,10 @@ that case, no one would ever be able to get the lock, so we’ve chosen to After we’ve acquired the lock, we can treat the return value, named `num` in this case, as a mutable reference to the data inside. The type system ensures -that we acquire a lock before using the value in `m`: `Mutex` is not an -`i32`, so we *must* acquire the lock to be able to use the `i32` value. We -can’t forget; the type system won’t let us access the inner `i32` otherwise. +that we acquire a lock before using the value in `m`. The type of `m` is +`Mutex`, not `i32`, so we *must* call `lock` to be able to use the `i32` +value. We can’t forget; the type system won’t let us access the inner `i32` +otherwise. As you might suspect, `Mutex` is a smart pointer. More accurately, the call to `lock` *returns* a smart pointer called `MutexGuard`, wrapped in a