remove the `T: Sync` requirement for `RwLock<T>: Send` by oconnor663 · Pull Request #45267 · rust-lang/rust

oconnor663 · 2017-10-13T23:06:15Z

That requirement makes sense for containers like Arc that don't
uniquely own their contents, but RwLock is not one of those.

This restriction was added in 380d23b, but it's not clear why. @hniksic
and I were discussing this on reddit. I might be totally wrong about this change being sound, but I'm super curious to find out :)

That requirement makes sense for containers like `Arc` that don't uniquely own their contents, but `RwLock` is not one of those. This restriction was added in rust-lang@380d23b, but it's not clear why.

rust-highfive · 2017-10-13T23:06:20Z

r? @aturon

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

cuviper · 2017-10-16T17:34:41Z

RwLock<T> without Sync behaves basically like a RefCell<T>, whose Send also only requires T: Send.

alexcrichton · 2017-10-19T14:53:33Z

Thanks for the PR! I think this change makes sense as well, especially along the lines of @cuviper's reasoning. I'm curious, though, what's the rationale for this change? Is code not compiling in the wild which should?

oconnor663 · 2017-10-19T16:19:17Z

This only came up for me because I was trying to make a table of the Send and Sync bounds that different "interior mutability" types take. I think looking at the precise API differences between Cell/RefCell/RwLock/Mutex is really helpful for illustrating how the safety rules work, and why they're designed the way they are. But yeah, I'd be kind of shocked if anyone ran into this in the wild.

alexcrichton · 2017-10-19T22:48:48Z

Hm ok, thanks for the info. In that sense I'd like to be extra careful with this, so to get some more eyes I'll....

@rfcbot fcp merge

rfcbot · 2017-10-19T23:48:15Z

Team member @alexcrichton has proposed to merge this. The next step is review by the rest of the tagged teams:

No concerns currently listed.

Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

hniksic · 2017-10-20T08:37:51Z

@alexcrichton Regarding which specific code doesn't compile and should, that would be any code that tries to send a RwLock<T> whose T is Send but not Sync to another thread. Whether such a code is useful in practice is another question.

I would still argue for the change to be accepted, for the following reasons:

the current bound is stricter than it needs to be, which can lead to incorrect compiler diagnostics. The compiler disallows a perfectly safe construct (sending a RwLock<T> to another thread where T is Send but not Sync), inferring that it is unsound on basis of incorrect (too strict) trait bound on RwLock.
the bound is confusing people who are attempting to learn about Rust's threading model by inspecting the stdlib sources.
finally, this PR simply reverts the bound to the one originally written, and likely intended by the author of RwLock. The commit that introduced the current bound was about an unrelated issue and by the looks of it, the bound tightening was accidental.

oconnor663 · 2017-10-20T15:17:27Z

For what it's worth, that commit also changed RwLock from being always Sync, to being Sync when the contents are Sync. That must've fixed a huge soundness hole? (Edit: @cuviper points out that I missed the impl bound.)

cuviper · 2017-10-20T16:19:13Z

At the time, all of the methods were in impl<T: Send + Sync>, so I'm not sure there's anything unsound you could have done with RwLock being unconditionally Sync itself.

aturon · 2017-10-25T14:48:51Z

cc @RalfJung

RalfJung · 2017-10-25T15:08:44Z

Indeed, RwLock: Send doesn't need the T: Sync bound. We have shown this in our formalization. I think I intended to submit a PR, but it seems I forgot to do so.

RalfJung · 2017-10-25T15:14:05Z

Actually there are some more unnecessary bounds, but they are implicit: RwLockReadGuard<'a, T>: Sync only needs T: Sync, while Rust also demands T: Send. Similar for the write guard.

oconnor663 · 2017-10-25T15:30:58Z

That is really cool :-D Should I add those removals to this PR, or better to make a separate one?

alexcrichton · 2017-10-31T22:12:59Z

@bors: r+

Thanks for taking a look @RalfJung!

bors · 2017-10-31T22:13:00Z

📌 Commit fbf6885 has been approved by alexcrichton

bors · 2017-11-01T04:32:22Z

⌛ Testing commit fbf6885 with merge 31bbe57...

@hniksic

remove the `T: Sync` requirement for `RwLock<T>: Send` That requirement makes sense for containers like `Arc` that don't uniquely own their contents, but `RwLock` is not one of those. This restriction was added in 380d23b, but it's not clear why. @hniksic and I [were discussing this on reddit](https://www.reddit.com/r/rust/comments/763o7r/blog_posts_introducing_lockfree_rust_comparing/dobcvbm/). I might be totally wrong about this change being sound, but I'm super curious to find out :)

bors · 2017-11-01T07:04:13Z

☀️ Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing 31bbe57 to master...

bstrie · 2017-11-07T23:50:33Z

@oconnor663 Feel free to make another PR removing the remaining bounds if you're up to it. :)

RalfJung · 2017-11-08T08:39:28Z

I already did: #45682

remove the T: Sync requirement for RwLock<T>: Send
fbf6885
That requirement makes sense for containers like `Arc` that don't uniquely own their contents, but `RwLock` is not one of those. This restriction was added in rust-lang@380d23b, but it's not clear why.

rust-highfive assigned aturon Oct 13, 2017

kennytm added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Oct 14, 2017

alexcrichton added the T-libs-api [DEPRECATED; DO NOT USE] label Oct 19, 2017

rfcbot added the proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. label Oct 19, 2017

kennytm added S-waiting-on-team and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 20, 2017

kennytm 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-team labels Nov 1, 2017

bors merged commit fbf6885 into rust-lang:masterNov 1, 2017

rfcbot removed the proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. label Nov 1, 2017

oconnor663 deleted the rwlock_send branch November 1, 2017 14:56

bluss added the relnotes Marks issues that should be documented in the release notes of the next release. label Nov 2, 2017

dtolnay mentioned this pull request Nov 18, 2017
Bounds for RwLock<T>: Send are unnecessarily restrictive #42934
Closed

Uh oh!

Uh oh!

Conversation

oconnor663 commented Oct 13, 2017

Uh oh!

rust-highfive commented Oct 13, 2017

Uh oh!

cuviper commented Oct 16, 2017

Uh oh!

alexcrichton commented Oct 19, 2017

Uh oh!

oconnor663 commented Oct 19, 2017

Uh oh!

alexcrichton commented Oct 19, 2017

Uh oh!

rfcbot commented Oct 19, 2017• edited by dtolnay Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

hniksic commented Oct 20, 2017

Uh oh!

oconnor663 commented Oct 20, 2017• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

cuviper commented Oct 20, 2017

Uh oh!

aturon commented Oct 25, 2017

Uh oh!

RalfJung commented Oct 25, 2017

Uh oh!

RalfJung commented Oct 25, 2017• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

oconnor663 commented Oct 25, 2017

Uh oh!

alexcrichton commented Oct 31, 2017

Uh oh!

bors commented Oct 31, 2017

Uh oh!

bors commented Nov 1, 2017

Uh oh!

bors commented Nov 1, 2017

Uh oh!

bstrie commented Nov 7, 2017

Uh oh!

RalfJung commented Nov 8, 2017

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

12 participants

rfcbot commented Oct 19, 2017•
edited by dtolnay
Loading

oconnor663 commented Oct 20, 2017•
edited
Loading

RalfJung commented Oct 25, 2017•
edited
Loading