Skip to content

Commit d940bf1

Browse files
committed
Rollup merge of rust-lang#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
2 parents 6da3f85 + a447124 commit d940bf1

File tree

1 file changed

+6
-1
lines changed

1 file changed

+6
-1
lines changed

src/doc/book/concurrency.md

Lines changed: 6 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -164,7 +164,7 @@ The same [ownership system](ownership.html) that helps prevent using pointers
164164
incorrectly also helps rule out data races, one of the worst kinds of
165165
concurrency bugs.
166166

167-
As an example, here is a Rust program that would have a data race in many
167+
As an example, here is a Rust program that could have a data race in many
168168
languages. It will not compile:
169169

170170
```ignore
@@ -197,6 +197,11 @@ thread, and the thread takes ownership of the reference, we'd have three owners!
197197
`data` gets moved out of `main` in the first call to `spawn()`, so subsequent
198198
calls in the loop cannot use this variable.
199199

200+
Note that this specific example will not cause a data race since different array
201+
indices are being accessed. But this can't be determined at compile time, and in
202+
a similar situation where `i` is a constant or is random, you would have a data
203+
race.
204+
200205
So, we need some type that lets us have more than one owning reference to a
201206
value. Usually, we'd use `Rc<T>` for this, which is a reference counted type
202207
that provides shared ownership. It has some runtime bookkeeping that keeps track

0 commit comments

Comments
 (0)