-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Improve error checking in mutex stub #3167
base: devel
Are you sure you want to change the base?
Conversation
Is there a reason this is in draft? It looks right. |
As mentioned above, I have not tested this PR. I won't have the opportunity to test it until next week. Do you want to merge this without testing? |
I can wait for you to run your tests. I just wanted to let CI have a crack at it too. That passed! |
Does CI actually test the stub mutex at all? I ask because this code turns out to be completely broken: I omitted a |
CI was not testing the behavior of the StubMutex because there wasn't much behavior to test in the first place (in hindsight, not the best idea). |
The default mutex stub is intended to be usable on any platform, even platforms that do not have threads and cannot block. This stub is inappropriate for applications that need to contend over mutexes. However, if inadvertently used in applications in a way that would result in mutex contention, they would silently allow incorrect and dangerous behavior. (Notably, they allowed multiple threads to enter the same critical section.) The new implementation still works on all platforms, and never blocks. However, it ensures that only one thread enters each critical section at a time. Attempting to acquire a mutex that is already taken will result in a failure to acquire the mutex, and likely an assertion. Because this should only occur in the case of a coding defect, this is an improvement over the previous implementation.
When a mutex fails to be taken or released, and it causes an assertion to trip, this change makes sure that enough information is provided to uniquely identify which mutex was at fault.
@LeStarch I've performed basic testing on this PR, so it should be ready to review. @thomas-bc I did not add tests for this mutex, because that appeared to require a bigger change. (Maybe a new platform is needed, since none of the default platforms include the stub mutex?) Do you want me to file a ticket for that? |
We can take care of adding those tests in this PR here if you'd like |
Sounds good. Please go ahead. |
Change Description
Replace the stub implementation of Os::Mutex with a more complete nonblocking implementation that still avoids platform dependencies.
Rationale
The default mutex stub is intended to be usable on any platform, even platforms that do not have threads and cannot block. This stub is inappropriate for applications that need to contend over mutexes. However, if inadvertently used in applications in a way that would result in mutex contention, they would silently allow incorrect and dangerous behavior. (Notably, they allowed multiple threads to enter the same critical section.)
The new implementation still works on all platforms, and never blocks. However, it ensures that only one thread enters each critical section at a time. Attempting to acquire a mutex that is already taken will result in a failure to acquire the mutex, and likely an assertion. Because this should only occur in the case of a coding defect, this is an improvement over the previous implementation.
Testing/Review Recommendations
No specific testing has been performed yet, so I am leaving this PR as a draft for the moment.
Future Work
It is possible that some existing programs work correctly by luck but happen to rely on the ability to have multiple threads acquire the same mutex. These programs could be broken by this upgrade. Therefore, this change in behavior should be documented in the release notes.