You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
yaksher opened this issue
Aug 29, 2023
· 1 comment
Labels
A-docsArea: documentation for any part of the project, including the compiler, standard library, and toolsT-libsRelevant to the library team, which will review and decide on the PR/issue.
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.
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.
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.
The text was updated successfully, but these errors were encountered:
yaksher
added
the
A-docs
Area: documentation for any part of the project, including the compiler, standard library, and tools
label
Aug 29, 2023
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
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.
A-docsArea: documentation for any part of the project, including the compiler, standard library, and toolsT-libsRelevant to the library team, which will review and decide on the PR/issue.
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.
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.
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.
The text was updated successfully, but these errors were encountered: