about summary refs log tree commit diff
path: root/library/std/src/thread
AgeCommit message (Collapse)AuthorLines
2021-10-08Fix minor std::thread documentation typoMarcelo Diop-Gonzalez-3/+3
callers of spawn_unchecked() need to make sure that the thread not outlive references in the passed closure, not the other way around.
2021-10-06Rollup merge of #89324 - yoshuawuyts:hardware-parallelism, r=m-ou-seManish Goregaokar-5/+7
Rename `std::thread::available_conccurrency` to `std::thread::available_parallelism` _Tracking issue: https://github.com/rust-lang/rust/issues/74479_ This PR renames `std::thread::available_conccurrency` to `std::thread::available_parallelism`. ## Rationale The API was initially named `std::thread::hardware_concurrency`, mirroring the [C++ API of the same name](https://en.cppreference.com/w/cpp/thread/thread/hardware_concurrency). We eventually decided to omit any reference to the word "hardware" after [this comment](https://github.com/rust-lang/rust/pull/74480#issuecomment-662045841). And so we ended up with `available_concurrency` instead. --- For a talk I was preparing this week I was reading through ["Understanding and expressing scalable concurrency" (A. Turon, 2013)](http://aturon.github.io/academic/turon-thesis.pdf), and the following passage stood out to me (emphasis mine): > __Concurrency is a system-structuring mechanism.__ An interactive system that deals with disparate asynchronous events is naturally structured by division into concurrent threads with disparate responsibilities. Doing so creates a better fit between problem and solution, and can also decrease the average latency of the system by preventing long-running computations from obstructing quicker ones. > __Parallelism is a resource.__ A given machine provides a certain capacity for parallelism, i.e., a bound on the number of computations it can perform simultaneously. The goal is to maximize throughput by intelligently using this resource. For interactive systems, parallelism can decrease latency as well. _Chapter 2.1: Concurrency is not Parallelism. Page 30._ --- _"Concurrency is a system-structuring mechanism. Parallelism is a resource."_ — It feels like this accurately captures the way we should be thinking about these APIs. What this API returns is not "the amount of concurrency available to the program" which is a property of the program, and thus even with just a single thread is effectively unbounded. But instead it returns "the amount of _parallelism_ available to the program", which is a resource hard-constrained by the machine's capacity (and can be further restricted by e.g. operating systems). That's why I'd like to propose we rename this API from `available_concurrency` to `available_parallelism`. This still meets the criteria we previously established of not attempting to define what exactly we mean by "hardware", "threads", and other such words. Instead we only talk about "concurrency" as an abstract resource available to our program. r? `@joshtriplett`
2021-10-04Add doc aliases to `std::thread::available_parallelism`Yoshua Wuyts-0/+2
2021-09-28Rename `std::thread::available_onccurrency` to ↵Yoshua Wuyts-5/+5
`std::thread::available_parallelism`
2021-09-16Remove an allocation from rt::initbjorn3-7/+5
Previously the thread name would first be heap allocated and then re-allocated to add a nul terminator. Now it will be heap allocated only once with nul terminator added form the start.
2021-08-07removed references to parent/child from std::thread documentationGodmar Back-31/+40
- also clarifies how thread.join and detaching of threads works - the previous prose implied that there is a relationship between a spawning thread and the thread being spawned, and that "child" threads couldn't outlive their parents unless detached, which is incorrect.
2021-07-29Fix may not to appropriate might not or must notAli Malik-2/+2
2021-07-10rename variableRalf Jung-2/+2
2021-07-10avoid reentrant lock acquire when ThreadIds run outRalf Jung-0/+1
2021-07-06rewrote documentation for thread::yield_now()Godmar Back-16/+17
The old documentation suggested the use of yield_now for repeated polling instead of discouraging it; it also made the false claim that channels are implementing using yield_now. (They are not, except for a corner case).
2021-06-24Use `#[non_exhaustive]` where appropriateJacob Pratt-4/+3
Due to the std/alloc split, it is not possible to make `alloc::collections::TryReserveError::AllocError` non-exhaustive without having an unstable, doc-hidden method to construct (which negates the benefits from `#[non_exhaustive]`.
2021-06-22Auto merge of #86527 - JohnTitor:rollup-cbu78g4, r=JohnTitorbors-162/+37
Rollup of 11 pull requests Successful merges: - #85054 (Revert SGX inline asm syntax) - #85182 (Move `available_concurrency` implementation to `sys`) - #86037 (Add `io::Cursor::{remaining, remaining_slice, is_empty}`) - #86114 (Reopen #79692 (Format symbols under shared frames)) - #86297 (Allow to pass arguments to rustdoc-gui tool) - #86334 (Resolve type aliases to the type they point to in intra-doc links) - #86367 (Fix comment about rustc_inherit_overflow_checks in abs().) - #86381 (Add regression test for issue #39161) - #86387 (Remove `#[allow(unused_lifetimes)]` which is now unnecessary) - #86398 (Add regression test for issue #54685) - #86493 (Say "this enum variant takes"/"this struct takes" instead of "this function takes") Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
2021-06-21Move `available_concurrency` implementation to `sys`Christiaan Dirkx-162/+37
2021-06-20Squashed implementation of the passAlex Vlasov-1/+1
2021-05-20std: Don't inline TLS accessor on MinGWAlex Crichton-13/+13
This is causing [issues] on Cargo's own CI for MinGW and given the original investigation there's no reason that MinGW should work when MSVC doesn't, this this tweaks the MSVC exception to being a Windows exception. [issues]: https://github.com/rust-lang/cargo/runs/2626676503?check_suite_focus=true#step:9:2453
2021-05-19Auto merge of #84876 - alexcrichton:inline-thread-locals-cross-crate, ↵bors-0/+24
r=Mark-Simulacrum std: Attempt again to inline thread-local-init across crates Issue #25088 has been part of `thread_local!` for quite some time now. Historical attempts have been made to add `#[inline]` to `__getit` in #43931, #50252, and #59720, but these attempts ended up not landing at the time due to segfaults on Windows. In the interim though with `const`-initialized thread locals AFAIK this is the only remaining bug which is why you might want to use `#[thread_local]` over `thread_local!`. As a result I figured it was time to resubmit this and see how it fares on CI and if I can help debugging any issues that crop up. Closes #25088
2021-05-18std: Attempt again to inline thread-local-init across cratesAlex Crichton-0/+24
Issue #25088 has been part of `thread_local!` for quite some time now. Historical attempts have been made to add `#[inline]` to `__getit` in #43931, #50252, and #59720, but these attempts ended up not landing at the time due to segfaults on Windows. In the interim though with `const`-initialized thread locals AFAIK this is the only remaining bug which is why you might want to use `#[thread_local]` over `thread_local!`. As a result I figured it was time to resubmit this and see how it fares on CI and if I can help debugging any issues that crop up. Closes #25088
2021-05-07Rollup merge of #84409 - mzohreva:mz/tls-dtors-before-join, r=jethrogbDylan DPC-0/+108
Ensure TLS destructors run before thread joins in SGX The excellent test is from ```@jethrogb``` For context see: https://github.com/rust-lang/rust/pull/83416#discussion_r617282907
2021-05-06join_orders_after_tls_destructors: ensure thread 2 is launched before thread ↵Mohsen Zohrevandi-8/+9
1 enters TLS destructors
2021-05-02Change 'NULL' to 'null'Brent Kerby-1/+1
2021-04-29Use atomics in join_orders_after_tls_destructors testMohsen Zohrevandi-34/+88
std::sync::mpsc uses thread locals and depending on the order TLS dtors are run `rx.recv()` can panic when used in a TLS dtor.
2021-04-21Ensure TLS destructors run before thread joins in SGXMohsen Zohrevandi-1/+54
2021-04-21Rollup merge of #84013 - CDirkx:fmt, r=m-ou-seMara Bos-5/+5
Replace all `fmt.pad` with `debug_struct` This replaces any occurrence of: - `f.pad("X")` with `f.debug_struct("X").finish()` - `f.pad("X { .. }")` with `f.debug_struct("X").finish_non_exhaustive()` This is in line with existing formatting code such as https://github.com/rust-lang/rust/blob/125505306744a0a5bb01d62337260a95d9ff8d57/library/std/src/sync/mpsc/mod.rs#L1470-L1475
2021-04-21Replace all `fmt.pad` with `debug_struct`Christiaan Dirkx-5/+5
2021-04-18fix aliasing violations in thread_local_const_initRalf Jung-1/+1
2021-04-16std: Add a variant of thread locals with const initAlex Crichton-48/+223
This commit adds a variant of the `thread_local!` macro as a new `thread_local_const_init!` macro which requires that the initialization expression is constant (e.g. could be stuck into a `const` if so desired). This form of thread local allows for a more efficient implementation of `LocalKey::with` both if the value has a destructor and if it doesn't. If the value doesn't have a destructor then `with` should desugar to exactly as-if you use `#[thread_local]` given sufficient inlining. The purpose of this new form of thread locals is to precisely be equivalent to `#[thread_local]` on platforms where possible for values which fit the bill (those without destructors). This should help close the gap in performance between `thread_local!`, which is safe, relative to `#[thread_local]`, which is not easy to use in a portable fashion.
2021-03-27Use DebugStruct::finish_non_exhaustive() in std.Mara Bos-1/+4
2021-03-21Use io::Error::new_const everywhere to avoid allocations.Mara Bos-5/+5
2021-02-10Rollup merge of #79849 - Digital-Chaos:sleep-zero, r=m-ou-seYuki Okushi-0/+9
Clarify docs regarding sleep of zero duration Clarify that the behaviour of sleep() when given a duration of zero is actually platform specific.
2021-01-15Update library/std/src/thread/mod.rs James Wright-0/+1
Fix link reference Co-authored-by: Joshua Nelson <joshua@yottadb.com>
2021-01-15Clarify difference between unix/windows behaviourJames Wright-0/+8
Updated to specify the underlying syscalls
2020-12-18Recommend panic::resume_unwind instead of panicking.Corey Farwell-7/+12
Fixes https://github.com/rust-lang/rust/issues/79950.
2020-11-22Drop support for cloudabi targetsLzu Tao-1/+0
2020-11-10Merge set_panic and set_print into set_output_capture.Mara Bos-3/+3
There were no use cases for setting them separately. Merging them simplifies some things.
2020-11-07Convert a bunch of intra-doc linksCamelid-2/+1
2020-10-22Capture output from threads spawned in testsTyler Mandry-0/+5
Fixes #42474.
2020-10-16Add std::thread::available_concurrencyYoshua Wuyts-0/+163
2020-10-02Rollup merge of #77147 - fusion-engineering-forks:static-mutex, r=dtolnayYuki Okushi-3/+2
Split sys_common::Mutex in StaticMutex and MovableMutex. The (unsafe) `Mutex` from `sys_common` had a rather complicated interface. You were supposed to call `init()` manually, unless you could guarantee it was neither moved nor used reentrantly. Calling `destroy()` was also optional, although it was unclear if 1) resources might be leaked or not, and 2) if `destroy()` should only be called when `init()` was called. This allowed for a number of interesting (confusing?) different ways to use this `Mutex`, all captured in a single type. In practice, this type was only ever used in two ways: 1. As a static variable. In this case, neither `init()` nor `destroy()` are called. The variable is never moved, and it is never used reentrantly. It is only ever locked using the `LockGuard`, never with `raw_lock`. 2. As a `Box`ed variable. In this case, both `init()` and `destroy()` are called, it will be moved and possibly used reentrantly. No other combinations are used anywhere in `std`. This change simplifies things by splitting this `Mutex` type into two types matching the two use cases: `StaticMutex` and `MovableMutex`. The interface of both new types is now both safer and simpler. The first one does not call nor expose `init`/`destroy`, and the second one calls those automatically in its `new()` and `Drop` functions. Also, the locking functions of `MovableMutex` are no longer unsafe. --- This will also make it easier to conditionally box mutexes later, by moving that decision into sys/sys_common. Some of the mutex implementations (at least those of Wasm and 'sys/unsupported') are safe to move, so wouldn't need a box. ~~(But that's blocked on #76932 for now.)~~ (See #77380.)
2020-09-27Move thread parker to sys_common.Mara Bos-224/+1
2020-09-27Add notes about memory ordering to futex parker implementation.Mara Bos-0/+20
2020-09-27Move linux-specific futex code into `sys` module.Mara Bos-36/+3
2020-09-27Fix warning.Mara Bos-1/+1
2020-09-27Mark unpark() as #[inline].Mara Bos-0/+2
2020-09-27Add fast futex-based thread parker for Linux.Mara Bos-123/+231
2020-09-27Move thread parker to a separate module.Mara Bos-112/+142
2020-09-27Split sys_common::Mutex in StaticMutex and MovableMutex.Mara Bos-3/+2
The (unsafe) Mutex from sys_common had a rather complicated interface. You were supposed to call init() manually, unless you could guarantee it was neither moved nor used reentrantly. Calling `destroy()` was also optional, although it was unclear if 1) resources might be leaked or not, and 2) if destroy() should only be called when `init()` was called. This allowed for a number of interesting (confusing?) different ways to use this Mutex, all captured in a single type. In practice, this type was only ever used in two ways: 1. As a static variable. In this case, neither init() nor destroy() are called. The variable is never moved, and it is never used reentrantly. It is only ever locked using the LockGuard, never with raw_lock. 2. As a Boxed variable. In this case, both init() and destroy() are called, it will be moved and possibly used reentrantly. No other combinations are used anywhere in `std`. This change simplifies things by splitting this Mutex type into two types matching the two use cases: StaticMutex and MovableMutex. The interface of both new types is now both safer and simpler. The first one does not call nor expose init/destroy, and the second one calls those automatically in its new() and Drop functions. Also, the locking functions of MovableMutex are no longer unsafe.
2020-09-26Auto merge of #74225 - poliorcetics:std-thread-unsafe-op-in-unsafe-fn, ↵bors-44/+127
r=joshtriplett Std/thread: deny unsafe op in unsafe fn Partial fix of #73904. This encloses `unsafe` operations in `unsafe fn` in `libstd/thread`. `@rustbot` modify labels: F-unsafe-block-in-unsafe-fn
2020-09-22Update library functions with stability attributesDylan MacKenzie-0/+2
This may not be strictly minimal, but all unstable functions also need a `rustc_const_unstable` attribute.
2020-09-21Fix missing unsafe block for target arch wasm32Alexis Bourget-3/+10
2020-09-21Fix accordingly to reviewAlexis Bourget-22/+20
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-23 03:09:17 +0000