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

Explain our RwLock implementation #71889

Merged
merged 4 commits into from
May 6, 2020
Merged

Explain our RwLock implementation #71889

merged 4 commits into from
May 6, 2020

Conversation

RalfJung
Copy link
Member

@RalfJung RalfJung commented May 4, 2020

Turns out that with the latest POSIX docs, our RwLock implementation is actually correct. However, we cannot fully rely on that due to bugs in older glibc (fix released in 2016). Update the comments to explain that.

I also clarified our Mutex docs a bit and fixed another instance of #55865.

r? @Amanieu
Fixes #53127

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label May 4, 2020
src/libstd/sys/unix/mutex.rs Outdated Show resolved Hide resolved
self.raw_unlock();
}
panic!("rwlock write lock would result in deadlock");
} else {
debug_assert_eq!(r, 0);
assert_eq!(r, 0);
Copy link
Member

Choose a reason for hiding this comment

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

Why did you change this from a debug assert? The docs for pthread_rwlock_wrlock specify that it only ever returns EDEADLK or 0.

Copy link
Member Author

Choose a reason for hiding this comment

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

Consistency -- I did the same in #55865. Seems cheap to check.

But if you want I can also make it a debug assertion again.

Copy link
Member

Choose a reason for hiding this comment

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

I would prefer making it a debug assert since this is a pretty hot path.

Copy link
Member Author

Choose a reason for hiding this comment

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

Okay, I did that and added an appropriate comment.
Is it generally the case that the list of error codes in the POSIX docs is exhaustive? I noticed the docs explicitly say "These functions shall not return an error code of [EINTR]" but do not say that for any of the other error codes.

Copy link
Member

Choose a reason for hiding this comment

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

They are supposed to be exhaustive in theory.

@Amanieu
Copy link
Member

Amanieu commented May 5, 2020

@bors r+

@bors
Copy link
Contributor

bors commented May 5, 2020

📌 Commit f9866f9 has been approved by Amanieu

@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 May 5, 2020
@Amanieu
Copy link
Member

Amanieu commented May 5, 2020

@bors rollup

Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this pull request May 5, 2020
Explain our RwLock implementation

Turns out that [with the latest POSIX docs](https://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_rwlock_wrlock.html), our `RwLock` implementation is actually correct. However, we cannot fully rely on that due to bugs in older glibc (fix released in 2016). Update the comments to explain that.

I also clarified our Mutex docs a bit and fixed another instance of rust-lang#55865.

r? @Amanieu
Fixes rust-lang#53127
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this pull request May 5, 2020
Explain our RwLock implementation

Turns out that [with the latest POSIX docs](https://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_rwlock_wrlock.html), our `RwLock` implementation is actually correct. However, we cannot fully rely on that due to bugs in older glibc (fix released in 2016). Update the comments to explain that.

I also clarified our Mutex docs a bit and fixed another instance of rust-lang#55865.

r? @Amanieu
Fixes rust-lang#53127
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this pull request May 5, 2020
Explain our RwLock implementation

Turns out that [with the latest POSIX docs](https://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_rwlock_wrlock.html), our `RwLock` implementation is actually correct. However, we cannot fully rely on that due to bugs in older glibc (fix released in 2016). Update the comments to explain that.

I also clarified our Mutex docs a bit and fixed another instance of rust-lang#55865.

r? @Amanieu
Fixes rust-lang#53127
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this pull request May 5, 2020
Explain our RwLock implementation

Turns out that [with the latest POSIX docs](https://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_rwlock_wrlock.html), our `RwLock` implementation is actually correct. However, we cannot fully rely on that due to bugs in older glibc (fix released in 2016). Update the comments to explain that.

I also clarified our Mutex docs a bit and fixed another instance of rust-lang#55865.

r? @Amanieu
Fixes rust-lang#53127
bors added a commit to rust-lang-ci/rust that referenced this pull request May 6, 2020
Rollup of 6 pull requests

Successful merges:

 - rust-lang#71510 (Btreemap iter intertwined)
 - rust-lang#71727 (SipHasher with keys initialized to 0 should just use new())
 - rust-lang#71889 (Explain our RwLock implementation)
 - rust-lang#71905 (Add command aliases from Cargo to x.py commands)
 - rust-lang#71914 (Backport 1.43.1 release notes to master)
 - rust-lang#71921 (explain the types used in the open64 call)

Failed merges:

r? @ghost
@bors bors merged commit e4bda61 into rust-lang:master May 6, 2020
@RalfJung RalfJung deleted the rwlock branch May 7, 2020 06:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Unix: RwLock is incorrect
4 participants