Rollup merge of #32538 - Manishearth:no-data-race, r=steveklabnik

Mention that it's not actually a data race

The example can't cause a data race since different indices are accesed.

(perhaps we should use an example where i iterates twice?)

r? @steveklabnik

1 files changed, 6 insertions, 1 deletions

diff --git a/src/doc/book/concurrency.md b/src/doc/book/concurrency.md
index 87d551b68df..82d2de7e3bf 100644
--- a/src/doc/book/concurrency.md
+++ b/src/doc/book/concurrency.md
@@ -164,7 +164,7 @@ The same [ownership system](ownership.html) that helps prevent using pointers
 incorrectly also helps rule out data races, one of the worst kinds of
 concurrency bugs.
 
-As an example, here is a Rust program that would have a data race in many
+As an example, here is a Rust program that could have a data race in many
 languages. It will not compile:
 
 ```ignore
@@ -197,6 +197,11 @@ thread, and the thread takes ownership of the reference, we'd have three owners!
 `data` gets moved out of `main` in the first call to `spawn()`, so subsequent
 calls in the loop cannot use this variable.
 
+Note that this specific example will not cause a data race since different array
+indices are being accessed. But this can't be determined at compile time, and in
+a similar situation where `i` is a constant or is random, you would have a data
+race.
+
 So, we need some type that lets us have more than one owning reference to a
 value. Usually, we'd use `Rc<T>` for this, which is a reference counted type
 that provides shared ownership. It has some runtime bookkeeping that keeps track