about summary refs log tree commit diff
path: root/library/std/src/sync/mutex.rs
AgeCommit message (Collapse)AuthorLines
2025-01-02Move some things to `std::sync::poison` and reexport them in `std::sync`Pavel Grigorenko-849/+0
2024-11-30Add value accessor methods to `Mutex` and `RwLock`EFanZh-6/+104
2024-09-29Fix std tests for wasm32-wasip2 targetNicola Krumschmidt-1/+1
2024-09-22Reformat using the new identifier sorting from rustfmtMichael Goulet-1/+1
2024-03-22docs(sync): normalize dot in fn summariesMultisampledNight-1/+1
2024-03-12std: move `Once` implementations to `sys`joboet-1/+1
2024-02-28remove Mutex::unlockHTGAzureX1212.-20/+0
2024-02-25Auto merge of #117107 - zachs18:mapped-mutex-guard, r=Amanieubors-0/+219
Implement `MappedMutexGuard`, `MappedRwLockReadGuard`, and `MappedRwLockWriteGuard`. ACP: https://github.com/rust-lang/libs-team/issues/260 Tracking issue: https://github.com/rust-lang/rust/issues/117108 <details> <summary> (Outdated) </summary> `MutexState`/`RwLockState` structs ~~Having `sys::(Mutex|RwLock)` and `poison::Flag` as separate fields in the `Mutex`/`RwLock` would require `MappedMutexGuard`/`MappedRwLockWriteGuard` to hold an additional pointer, so I combined the two fields into a `MutexState`/`RwLockState` struct. This should not noticeably affect perf or layout, but requires an additional field projection when accessing the former `.inner` or `.poison` fields (now `.state.inner` and `.state.poison`).~~ If this is not desired, then `MappedMutexGuard`/`MappedRwLockWriteGuard` can instead hold separate pointers to the two fields. </details> The doc-comments are mostly copied from the existing `*Guard` doc-comments, with some parts from `lock_api::Mapped*Guard`'s doc-comments. Unresolved question: Are more tests needed?
2024-02-23Apply suggestions from code reviewzachs18-3/+3
Co-authored-by: Amanieu d'Antras <amanieu@gmail.com>
2024-02-08Bump version placeholdersMark Rousskov-1/+1
2024-01-10Stabilize mutex_unpoison featureThayne McCombs-3/+1
Closes #96469 @rustbot +T-libs-api
2023-12-10Fix typo in `std::sync::Mutex` examplenaglis-1/+1
2023-12-05Specify behavior if the closure passed to *Guard::*map panics.Zachary S-28/+50
2023-12-05fix MappedMutexGuard::(try_)map doc typo.Zachary S-2/+2
2023-12-05Fix Condvar typo, add public re-exports of Mapped*Guard.Zachary S-2/+2
2023-12-05Add comment about `Mapped(Mutex|RwLockWrite)Guard` variance.Zachary S-12/+16
2023-12-05Implement `MappedMutexGuard`.Zachary S-0/+193
2023-04-19std: make `Debug` representations of `[Lazy, Once]*[Cell, Lock]` consistent ↵joboet-7/+1
with `Mutex` and `RwLock` `Mutex` prints `<locked>` as a field value when its inner value cannot be accessed, but the lazy types print a fixed string like "`OnceCell(Uninit)`". This could cause confusion if the inner type is a unit type named `Uninit` and does not respect the pretty-printing flag. With this change, the format message is now "`OnceCell(<uninit>)`", consistent with `Mutex`.
2023-03-20Apply suggestions from code reviewthe8472-3/+3
Co-authored-by: Josh Stone <cuviper@gmail.com>
2023-03-20Add block-based mutex unlocking exampleThe 8472-7/+17
2022-11-06std: remove lock wrappers in `sys_common`joboet-10/+6
2022-09-02Rollup merge of #97739 - a2aaron:let_underscore, r=estebankGuillaume Gomez-0/+1
Uplift the `let_underscore` lints from clippy into rustc. This PR resolves #97241. This PR adds three lints from clippy--`let_underscore_drop`, `let_underscore_lock`, and `let_underscore_must_use`, which are meant to capture likely-incorrect uses of `let _ = ...` bindings (in particular, doing this on a type with a non-trivial `Drop` causes the `Drop` to occur immediately, instead of at the end of the scope. For a type like `MutexGuard`, this effectively releases the lock immediately, which is almost certainly the wrong behavior) In porting the lints from clippy I had to copy over a bunch of utility functions from `clippy_util` that these lints also relied upon. Is that the right approach? Note that I've set the `must_use` and `drop` lints to Allow by default and set `lock` to Deny by default (this matches the same settings that clippy has). In talking with `@estebank` he informed me to do a Crater run (I am not sure what type of Crater run to request here--I think it's just "check only"?) On the linked issue, there's some discussion about using `must_use` and `Drop` together as a heuristic for when to warn--I did not implement this yet. r? `@estebank`
2022-06-19Auto merge of #97791 - m-ou-se:const-locks, r=m-ou-sebors-1/+3
Make {Mutex, Condvar, RwLock}::new() const. This makes it possible to have `static M: Mutex<_> = Mutex::new(..);` 🎉 Our implementations [on Linux](https://github.com/rust-lang/rust/pull/95035), [on Windows](https://github.com/rust-lang/rust/pull/77380), and various BSDs and some tier 3 platforms have already been using a non-allocating const-constructible implementation. As of https://github.com/rust-lang/rust/pull/97647, the remaining platforms (most notably macOS) now have a const-constructible implementation as well. This means we can finally make these functions publicly const. Tracking issue: https://github.com/rust-lang/rust/issues/93740
2022-06-09Avoid `thread::panicking()` in non-poisoning methods of `Mutex` and `RwLock`Josh Stone-3/+3
`Mutex::lock()` and `RwLock::write()` are poison-guarded against panics, in that they set the poison flag if a panic occurs while they're locked. But if we're already in a panic (`thread::panicking()`), they leave the poison flag alone. That check is a bit of a waste for methods that never set the poison flag though, namely `get_mut()`, `into_inner()`, and `RwLock::read()`. These use-cases are now split to avoid that unnecessary call.
2022-06-07Update library/std/src/sync/mutex.rsDylan DPC-1/+1
Co-authored-by: Weiyi Wang <wwylele@gmail.com>
2022-06-07Remove confusing sentence from `Mutex` docsNilstrieb-5/+4
The docs were saying something about "statically initializing" the mutex, and it's not clear what this means. Remove that part to avoid confusion.
2022-06-06Make {Mutex, Condvar, RwLock}::new() const.Mara Bos-0/+1
2022-06-06Make all {Mutex, Condvar, RwLock}::new #[inline].Mara Bos-1/+2
2022-06-05Add diagnostic items to MutexGuard and RwLock GuardsAaron Kofsky-0/+1
I forgot to add the diagnostic to the actual types in `std` earlier.
2022-05-20Auto merge of #96422 - tmccombs:mutex-unpoison, r=m-ou-sebors-0/+39
Add functions to un-poison Mutex and RwLock See discussion at https://internals.rust-lang.org/t/unpoisoning-a-mutex/16521/3
2022-05-20Remove references to guards in documentation for clear_poisonThayne McCombs-5/+5
2022-05-19Change clear_poison to take the lock instead of a guardThayne McCombs-4/+9
2022-05-06Mark locks in std lib with clippy::has_significant_dropPreston From-0/+1
2022-04-27Add tracking issue number for mutex_unpoisonThayne McCombs-1/+1
2022-04-26Add functions to un-poison Mutex and RwLockThayne McCombs-0/+34
See discussion at https://internals.rust-lang.org/t/unpoisoning-a-mutex/16521/3
2022-01-28update cfg(bootstrap)sPietro Albini-5/+2
2021-10-03Practice diagnostic message conventionHirochika Matsumoto-1/+1
2021-10-02Make diangostic item names consistentCameron Steffen-1/+1
2021-09-28ref/refmutGus Wynn-1/+1
2021-09-27lock typesGus Wynn-0/+6
2021-07-01Move Mutex::unlock to T: ?SizedMark Mansi-20/+20
2021-05-24minor rewording after reviewTaylor Yu-2/+2
Use "the `WouldBlock` error" instead of "the error `WouldBlock`", etc.
2021-05-20doc: clarify Mutex::try_lock, etc. errorsTaylor Yu-2/+8
Clarify error returns from Mutex::try_lock, RwLock::try_read, RwLock::try_write to make it more obvious that both poisoning and the lock being already locked are possible errors.
2021-04-28Simplify `Mutex::into_inner`Benoît du Garreau-19/+2
2021-04-22Move `sys_common::poison` to `sync::poison`Christiaan Dirkx-1/+1
2021-03-27Improve Debug implementations of Mutex and RwLock.Mara Bos-4/+8
They now show the poison flag and use debug_non_exhaustive.
2021-02-18add Mutex::unlockmark-0/+20
2020-10-07(docs): make mutex error comment consistent with codebaseSteve Manuel-1/+1
2020-09-27Split sys_common::Mutex in StaticMutex and MovableMutex.Mara Bos-26/+4
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-20Replace unneeded `unsafe` calls to `.get()` with calls to `.get_mut()`Daniel Henry-Mantilla-3/+1
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-23 12:56:19 +0000