-
Notifications
You must be signed in to change notification settings - Fork 225
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
lock_api: Mark unlock and friends unsafe. #243
Conversation
This fixes #242. |
@brain0 Are you still working on this? Could you please address my review comments so that I can merge this. |
Yes, sorry, I'll take care of it |
There is a new conflict, would you prefer this to be solved via merge or rebase? |
I solved the conflict with a merge to simplify review. If you prefer I rebase it, I can still do that. |
A rebase is usually the preferred way to resolve conflicts. |
Unlocking a Mutex that you do not hold is likely to cause undefined behavior. If unlock() is a safe method, then it likely impossible to provide a sound and efficient implemention of the method. Since this API is usually only called by the lock_api Mutex structs, this change should be invisible to the users, but clarifies what guarantees implementers must make.
…k is being held unsafe.
Okay, done. |
Methods like
unlock
,bump
,upgrade
,downgrade
and similar all assume that a certain kind of lock is being held. Since the wrapper mutex and guard types in thelock_api
crate guarantee that these APIs are always used correctly, these methods are made unsafe to allow implementers to skip checks for these conditions. This allows sound and efficient implementations of these traits.I hope I did not forget any methods or screw up any comments.