Guide: ownership #16487
Guide: ownership #16487
Conversation
|
|
||
| If two distinct bindings share a pointer, and the memory that pointer points to | ||
| is immutable, then there are no problems. But if it's mutable, both pointers | ||
| can attempt to write to the memory at the same time, causing a **data race**. |
There was a problem hiding this comment.
"Data races" happen in concurrent systems, to my knowledge. They can be caused by pointer aliasing, but we'd better mention a simpler concept. Iterator invalidation comes to my mind. Unfortunately, it's specific to C++, so perhaps someone else has a better idea.
There was a problem hiding this comment.
Personally, the term "data race" is meaningful, whereas I've never heard the term "iterator invalidation"
There was a problem hiding this comment.
I'm not 100% sure about the term, but this concept DOES also protect against concurrency-based data races as well, so this isn't outright wrong, exactly. Maybe should point out both, and be more explicit?
There was a problem hiding this comment.
You could also just fall back to a generic term everyone has heard, "race condition", and then elaborate later.
There was a problem hiding this comment.
It's most common with a pointer to a mutable structure and another pointer to its part, mutable or not. In C++, an insertion into a vector can invalidate all its iterators and references. There are several other rules. In Rust, every data structure is borrowed for the lifetime of an iterator.
Iterator invalidation is basically pointer invalidation: mutation occurs from some other place, and suddenly a pointer points to uninitialized/invalid memory.
There was a problem hiding this comment.
I also consider it a data race (or iterator-invalidation problem) if one borrower tries to write while another tries to read.
There was a problem hiding this comment.
I'm going to go with 'race condition', as that seems most general.
|
I've now updated the text with all of the current feedback. I moved a section around a bit to make which rule i'm talking about more clear. |
|
This looks great now! Great, job @steveklabnik |
Whew. This section was so important, I saved it for last. /cc @wycats, @nikomatsakis
…=Veykril Remove unnecessary `.as_ref()` in generate getter assist Resolves rust-lang#12389
Whew. This section was so important, I saved it for last.
/cc @wycats, @nikomatsakis