-
Notifications
You must be signed in to change notification settings - Fork 5.6k
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
Potential Issue in SharedMutex Implementation #2280
Comments
Thanks for bringing this up! I reviewed the TLA+ model, and there are a few areas that might be causing the unexpected behavior: Refactor the Init Action: Start by confirming that all variables are properly initialized according to your intended starting state. Any deviation might cause issues during the state exploration. Review State Transitions: Revisit the Next action, ensuring that each operation transition correctly reflects the real-world behavior of the mutex. Pay attention to the order of operations and conditions. Run TLC Model Checker: Use different configurations in TLC to identify potential pitfalls. Carefully analyze any counterexamples it generates, as these can guide you towards the root cause of the problem. |
I've been working with a simplified TLA+ model to verify the behavior of SharedMutex. During this process, I encountered an unexpected issue.
TLA+ Model and Configuration
When running the command
tlc LockModel.tla -config LockModel.cfg -deadlock
, TLC reports the following error:Code Path Analysis
The issue seems to occur under the following conditions:
The caller attempts to acquire an exclusive lock at:
lockExclusiveImpl
returnstrue
, indicating the exclusive lock is held: SharedMutex.h#L1262.The problem arises because the check for deferred readers is not atomic. It's possible for a caller attempting to acquire a read lock to manipulate the deferred slots. Specifically, setting slot 2, encountering an exclusive lock, and then releasing slot 1, effectively moving slot 2 to slot 1, which might bypass
applyDeferredReaders
.Uncertainty
The entire locking mechanism is quite complex for me, and I'm not certain if the TLA+ error is due to a misunderstanding on my part or if it indicates a genuine bug. I would appreciate the opportunity to discuss this further. Thank you for your attention.
The text was updated successfully, but these errors were encountered: