mikros/rust
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

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

Browse Source 
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
This commit is contained in:
Steve Klabnik 2016-04-06 12:12:07 -07:00
commit 2bbdbd267a
1 changed files with 6 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
src/doc/book/concurrency.md
View File

@ -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