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

Promise made by the std::sync::RwLock documentation contradicted on next line and by pthread #115338

Open
yaksher opened this issue Aug 29, 2023 · 1 comment
Labels
A-docs Area: documentation for any part of the project, including the compiler, standard library, and tools T-libs Relevant to the library team, which will review and decide on the PR/issue.

Comments

@yaksher
Copy link

yaksher commented Aug 29, 2023

Location

The relevant documentation page is: Struct std::sync::RwLock

The error is in the second paragraph (0 indexed or not counting the one line "A reader-writer lock" at the start, whichever makes you happier) on the final sentence: "An RwLock will allow any number of readers to acquire the lock as long as a writer is not holding the lock."

Summary

The line in question states that "the lock will allow any number of readers to acquire the lock as long as a writer is not holding the lock." This has one error I'm sure of, along with I believe a second error.

  1. The following line states that "the priority policy of the lock is dependent on the underlying operating system" and that the lock can potentially block on a read request even if the lock is not held by a writer, as long as writer is waiting for the lock. One of these lines must be wrong, and given that I believe this issue implies that on some platforms, RwLock serves as wrapper for the pthread implementation which itself says that this policy is "implementation dependent", it appears that the former is wrong.

  2. The line in question also states that "any number of readers..." which itself may be wrong in cases where RwLock serves as a pthread wrapper because the pthread standard states that "the maximum number of simultaneous read locks that an implementation guarantees can be applied to a read-write lock shall be implementation-defined" and certainly doesn't promise that it is unbounded.

@yaksher yaksher added the A-docs Area: documentation for any part of the project, including the compiler, standard library, and tools label Aug 29, 2023
@rustbot rustbot added the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Aug 29, 2023
@Noratrieb Noratrieb added T-libs Relevant to the library team, which will review and decide on the PR/issue. C-discussion Category: Discussion or questions that doesn't represent real issues. and removed needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. C-discussion Category: Discussion or questions that doesn't represent real issues. labels Aug 29, 2023
@m-ou-se
Copy link
Member

m-ou-se commented Mar 21, 2024

Yeah, you're right. That documentation should be clarified/corrected.

"An RwLock will allow any number of readers to acquire the lock as long as a writer is not holding the lock."

I think that sentence's only purpose was to explain the "multiple readers xor one writer" behaviour, but was accidentally written in a way that seems to imply more properties (unbounded readers, not prioritizing writers, ..) that an RwLock doesn't have or guarantee.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-docs Area: documentation for any part of the project, including the compiler, standard library, and tools T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

4 participants