Rwlock downgrade

[connortsui20]

Tracking Issue: #128203

This PR adds a downgrade method for RwLock / RwLockWriteGuard on all currently supported platforms.

Outstanding questions:

• Does the futex.rs change affect performance at all? It doesn't seem like it will but we can't be certain until we bench it...
• Should the SOLID platform implementation be ported over to the queue.rs implementation to allow it to support downgrades?

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @Amanieu (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

[connortsui20]

@kawadakk I am very unfamiliar with the SOLID platform, do you know if the external rwlock implementation for SOLID supports downgrade?

[Amanieu]

r? @joboet

[bors]

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

[bors]

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

[kawadakk]

@connortsui20 The SOLID platform doesn't support the downgrade operation for rwlocks. Migrating to the queue implementation is a possible (and likely more performant) option, though this would mean losing priority-ordered queueing.

[connortsui20]

Migrating to the queue implementation is a possible (and likely more performant) option, though this would mean losing priority-ordered queueing.

This is not strictly necessary, as we could make the downgrade operation a noop where we just don't allow other readers to read. However there are some things that I think need to be discussed first (see #128203).

[joboet]

I'm reassigning this, I shouldn't review my own code...

r? libs

[rustbot]

There are merge commits (commits with multiple parents) in your changes. We have a no merge policy so these commits will need to be removed for this pull request to be merged.

You can start a rebase with the following commands:

$ # rebase
$ git pull --rebase https://github.com/rust-lang/rust.git master
$ git push --force-with-lease

The following commits are merge commits:

• d4e15f3
• 5e84405
• 97c8038
• 050ac42
• 7b69de9
• 2b3af27

[tgross35]

Sorry about this, I didn't get the chance to review the rest of this. I can do that when I'm back later this month, but in case somebody wants to pick it up before then.

r? @libs

[Mark-Simulacrum]

r? tgross35

I'll set the reviewer back for now, since I don't currently have the bandwidth to dig in here.

[rustbot]

Could not assign reviewer from: tgross35.
User(s) tgross35 are either the PR author, already assigned, or on vacation, and there are no other candidates.
Use r? to specify someone else to assign.

[connortsui20]

r? @libs

[connortsui20]

Should I split out the queue implementation changes (of which a significant portion are just documentation changes) into a separate PR to keep this one more simple? I understand that the queue implementation is somewhat tricky so it might deserve its own PR

[Noratrieb]

@m-ou-se @kprotty in case you have input on the queue implementation