From a44712496379844c30bb8a37c725cd4687d5c395 Mon Sep 17 00:00:00 2001
From: Manish Goregaokar <manishsmail@gmail.com>
Date: Mon, 28 Mar 2016 03:25:23 +0530
Subject: [PATCH] Mention that it's not actually a data race

Conflicts:
	src/doc/book/concurrency.md
---
 src/doc/book/concurrency.md | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/src/doc/book/concurrency.md b/src/doc/book/concurrency.md
index 87d551b68df07..82d2de7e3bfd5 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