std: use a mutex for ThreadId generation if available#149476
std: use a mutex for ThreadId generation if available#149476joboet wants to merge 1 commit intorust-lang:mainfrom
ThreadId generation if available#149476Conversation
|
rustbot has assigned @Mark-Simulacrum. Use |
| #[cold] | ||
| fn exhausted() -> ! { | ||
| panic!("failed to generate unique thread ID: bitspace exhausted") | ||
| rtabort!("failed to generate unique thread ID: bitspace exhausted") |
There was a problem hiding this comment.
Panicking may allocate, so it shouldn't be used here either.
|
This violates the contract we established that the global allocator may call So if there's a platform without 64-bit atomics but which has an allocating |
No it won't, the |
|
@joboet Actually, re-reading the code, neither If we were to adopt #147342 I think we might be able to get rid of the desperate path altogether. |
The problem is that not all threads are spawned by Rust – and on foreign threads, it's the first call to |
|
I hadn't considered foreign threads, you're right. |
This comment has been minimized.
This comment has been minimized.
|
This still invokes |
| } | ||
| } | ||
|
|
||
| /// Generates a new unique thread ID. |
There was a problem hiding this comment.
| /// Generates a new unique thread ID. | |
| /// Generates a new unique thread ID. Might use the global allocator. |
ThreadId generation fallback path: avoid spurious yields Fixes rust-lang/miri#4737 Alternative to rust-lang#149476 Cc `@orlp` `@joboet`
ThreadId generation fallback path: avoid spurious yields Fixes rust-lang/miri#4737 Alternative to #149476 Cc `@orlp` `@joboet`
ThreadId generation fallback path: avoid spurious yields Fixes rust-lang/miri#4737 Alternative to #149476 Cc `@orlp` `@joboet`
ThreadId generation fallback path: avoid spurious yields Fixes rust-lang/miri#4737 Alternative to #149476 Cc `@orlp` `@joboet`
67c2ddd to
3c7ee48
Compare
|
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
|
The job Click to see the possible cause of the failure (guessed by this bot) |
ThreadId generation fallback path: avoid spurious yields Fixes #4737 Alternative to rust-lang/rust#149476 Cc `@orlp` `@joboet`
|
I don't think this really matters, closing. |
ThreadId generation fallback path: avoid spurious yields Fixes rust-lang/miri#4737 Alternative to rust-lang#149476 Cc `@orlp` `@joboet`
Fixes rust-lang/miri#4737
#144465 changed
ThreadId::newto use a spinlock on platforms without 64-bit atomics. This introduces subtle scheduling changes such as the one described in rust-lang/miri#4737 and isn't ideal from a performance perspective either. The necessity of avoidingMutexis not always given however – it only needs to be avoided if the thread handle is lazily initialised. For normal Rust threads however,stdgenerates the thread id inside the spawning logic, where allocation is expected. Thus this PR renames the currentThreadId::newtodesperate_newand reintroduces a versionThreadId::newthat employs aMutexto synchronise access to the inner spin-lock.CC @RalfJung @orlp