Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Split sys_common::Mutex in StaticMutex and MovableMutex. #77147

Merged
merged 2 commits into from
Oct 2, 2020

Conversation

m-ou-se
Copy link
Member

@m-ou-se m-ou-se commented Sep 24, 2020

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.


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.)

@rustbot rustbot added the T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. label Sep 24, 2020
@rust-highfive
Copy link
Collaborator

r? @KodrAus

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Sep 24, 2020
@m-ou-se
Copy link
Member Author

m-ou-se commented Sep 24, 2020

@rustbot modify labels: +A-concurrency +C-cleanup

@rustbot rustbot added A-concurrency Area: Concurrency C-cleanup Category: PRs that clean code up or issues documenting cleanup. labels Sep 24, 2020
@bors
Copy link
Contributor

bors commented Sep 27, 2020

☔ The latest upstream changes (presumably #77154) made this pull request unmergeable. Please resolve the merge conflicts.

Note that reviewers usually do not review pull requests until merge conflicts are resolved! Once you resolve the conflicts, you should change the labels applied by bors to indicate that your PR is ready for review. Post this as a comment to change the labels:

@rustbot modify labels: +S-waiting-on-review -S-waiting-on-author

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.
This test checks if the compiler complains about accesing a private
field before complaining (or crashing) about the private function on it
not marked as stable/unstable.

The interface of the internal type (sys_common's Mutex) used for this
was changed. With this change, it uses another function to test for the
same issue.
Copy link
Member

@dtolnay dtolnay left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a great improvement. Thank you!

@dtolnay
Copy link
Member

dtolnay commented Oct 1, 2020

@bors r+

@bors
Copy link
Contributor

bors commented Oct 1, 2020

📌 Commit 825dda8 has been approved by dtolnay

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 1, 2020
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this pull request Oct 1, 2020
…ex, r=dtolnay

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  rust-lang#76932 for now.)~~ (See rust-lang#77380.)
bors added a commit to rust-lang-ci/rust that referenced this pull request Oct 2, 2020
Rollup of 11 pull requests

Successful merges:

 - rust-lang#76851 (Fix 'FIXME' about using NonZeroU32 instead of u32.)
 - rust-lang#76979 (Improve std::sys::windows::compat)
 - rust-lang#77111 (Stabilize slice_ptr_range.)
 - rust-lang#77147 (Split sys_common::Mutex in StaticMutex and MovableMutex.)
 - rust-lang#77312 (Remove outdated line from `publish_toolstate` hook)
 - rust-lang#77362 (Fix is_absolute on WASI)
 - rust-lang#77375 (rustc_metadata: Do not forget to encode inherent impls for foreign types)
 - rust-lang#77385 (Improve the example for ptr::copy)
 - rust-lang#77389 (Fix some clippy lints)
 - rust-lang#77399 (BTreeMap: use Unique::from to avoid a cast where type information exists)
 - rust-lang#77429 (Link `new` method in `DefautHasher`s doc)

Failed merges:

r? `@ghost`
@bors bors merged commit 1c4a5f8 into rust-lang:master Oct 2, 2020
@rustbot rustbot added this to the 1.48.0 milestone Oct 2, 2020
@dtolnay dtolnay assigned dtolnay and unassigned KodrAus Oct 2, 2020
stlankes added a commit to hermit-os/rust that referenced this pull request Oct 12, 2020
rust-lang#77147 simplifies things by splitting this Mutex type
into two types matching the two use cases: StaticMutex and MovableMutex.
To support the behavior of StaticMutex, we move part of the mutex
implementation into libstd.
bors added a commit to rust-lang-ci/rust that referenced this pull request Dec 10, 2020
…=Mark-Simulacrum

Enforce no-move rule of ReentrantMutex using Pin and fix UB in stdio

A `sys_common::ReentrantMutex` may not be moved after initializing it with `.init()`. This was not enforced, but only stated as a requirement in the comments on the unsafe functions. This change enforces this no-moving rule using `Pin`, by changing `&self` to a `Pin` in the `init()` and `lock()` functions.

This uncovered a bug I introduced in rust-lang#77154: stdio.rs (the only user of ReentrantMutex) called `init()` on its ReentrantMutexes while constructing them in the intializer of `SyncOnceCell::get_or_init`, which would move them afterwards. Interestingly, the ReentrantMutex unit tests already had the same bug, so this invalid usage has been tested on all (CI-tested) platforms for a long time. Apparently this doesn't break badly on any of the major platforms, but it does break the rules.\*

To be able to keep using SyncOnceCell, this adds a `SyncOnceCell::get_or_init_pin` function, which makes it possible to work with pinned values inside a (pinned) SyncOnceCell. Whether this function should be public or not and what its exact behaviour and interface should be if it would be public is something I'd like to leave for a separate issue or PR. In this PR, this function is internal-only and marked with `pub(crate)`.

\* Note: That bug is now included in 1.48, while this patch can only make it to ~~1.49~~ 1.50. We should consider the implications of 1.48 shipping with a wrong usage of `pthread_mutex_t` / `CRITICAL_SECTION` / .. which technically invokes UB according to their specification. The risk is very low, considering the objects are not 'used' (locked) before the move, and the ReentrantMutex unit tests have verified this works fine in practice.

Edit: This has been backported and included in 1.48. And soon 1.49 too.

---

In future changes, I want to push this usage of Pin further inside `sys` instead of only `sys_common`, and apply it to all 'unmovable' objects there (`Mutex`, `Condvar`, `RwLock`). Also, while `sys_common`'s mutexes and condvars are already taken care of by rust-lang#77147 and rust-lang#77648, its `RwLock` should still be made movable or get pinned.
bors added a commit to rust-lang-ci/rust that referenced this pull request Apr 28, 2021
…-ou-se

Simplify `Mutex::into_inner`

Thanks to rust-lang#77147, `Mutex` do not implement `Drop` directly, so the old unsafe implementation of `into_inner` is not relevant anymore.
JohnTitor added a commit to JohnTitor/rust that referenced this pull request Jun 10, 2021
Multiple improvements to RwLocks

This PR replicates rust-lang#77147, rust-lang#77380 and rust-lang#84650 on RWLocks :
- Split `sys_common::RWLock` in `StaticRWLock` and `MovableRWLock`
- Unbox rwlocks on some platforms (Windows, Wasm and unsupported)
- Simplify `RwLock::into_inner`

Notes to reviewers :
- For each target, I copied `MovableMutex` to guess if `MovableRWLock` should be boxed.
- ~A comment says that `StaticMutex` is not re-entrant, I don't understand why and I don't know whether it applies to `StaticRWLock`.~

r? `@m-ou-se`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-concurrency Area: Concurrency C-cleanup Category: PRs that clean code up or issues documenting cleanup. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants