-
Notifications
You must be signed in to change notification settings - Fork 13.6k
Open
Labels
A-atomicArea: Atomics, barriers, and sync primitivesArea: Atomics, barriers, and sync primitivesA-docsArea: Documentation for any part of the project, including the compiler, standard library, and toolsArea: Documentation for any part of the project, including the compiler, standard library, and toolsA-threadArea: `std::thread`Area: `std::thread`C-feature-requestCategory: A feature request, i.e: not implemented / a PR.Category: A feature request, i.e: not implemented / a PR.T-libs-apiRelevant to the library API team, which will review and decide on the PR/issue.Relevant to the library API team, which will review and decide on the PR/issue.
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?
Metadata
Metadata
Assignees
Labels
A-atomicArea: Atomics, barriers, and sync primitivesArea: Atomics, barriers, and sync primitivesA-docsArea: Documentation for any part of the project, including the compiler, standard library, and toolsArea: Documentation for any part of the project, including the compiler, standard library, and toolsA-threadArea: `std::thread`Area: `std::thread`C-feature-requestCategory: A feature request, i.e: not implemented / a PR.Category: A feature request, i.e: not implemented / a PR.T-libs-apiRelevant to the library API team, which will review and decide on the PR/issue.Relevant to the library API team, which will review and decide on the PR/issue.
Type
Projects
Milestone
Relationships
Development
Select code repository
Activity
Noratrieb commentedon Jan 3, 2024
@rustbot label -needs-triage +A-docs +T-libs-api +C-feature-request +A-thread +A-atomic