Document memory ordering guarantees for `std::thread::spawn()`
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 119k
- Forks
- 16.1k
- PR merge metrics
- PR metrics pending
Description
The documentation for std::thread::JoinHandle::join() guarantees that all memory operations performed by the joined thread are visible in the joining thread before join() returns:
[...] In other words, all operations performed by that thread happen before all operations that happen after join returns.
The documentation does not give such guarantees for std::thread::spawn() and the associated [Builder::spawn].
Obviously, such guarantee already exists implicitly:
fn main() {
let s = "Foo".to_string();
std::thread::spawn(move || {
// All memory-operations performed by the spawning thread
// are visible (happened-before) when the closure starts
// executing, even though they have no explicit ordering.
println!("{s}");
}).join().unwrap();
}
Can we update the documentation on std::thread::spawn() (and friends) to explicitly make this guarantee?
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the linked documentation for std:🧵:spawn(), Builder::spawn, and JoinHandle::join(). Compare the existing memory-ordering language and document the corresponding guarantee for thread creation. Done means the spawn APIs explicitly state the ordering guarantee consistently with join().
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- documentation
- Issue type
- Documentation
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Stale
- Clarity
- Clearly specified
- Newbie friendliness
- 52/100