Skip to content

Commit

Permalink
Rollup merge of rust-lang#32538 - Manishearth:no-data-race, r=stevekl…
Browse files Browse the repository at this point in the history
…abnik

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
  • Loading branch information
Manishearth committed Apr 6, 2016
2 parents 6da3f85 + a447124 commit d940bf1
Showing 1 changed file with 6 additions and 1 deletion.
7 changes: 6 additions & 1 deletion src/doc/book/concurrency.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down Expand Up @@ -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
Expand Down

0 comments on commit d940bf1

Please sign in to comment.