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
sync: detect recursive locks, somehow #33584
Comments
The short answer is that it's infeasible. It's also I think an error to try. Yes, adjacent calls like this are a bug but the point of locking is to keep someone out. It's not even necessarily an error for the same goroutine to call Lock twice: it could be the job of another one to unlock. This works:
https://play.golang.org/p/O3pOKFeCkRG Now that's clearly a ridiculous example but the model of its computation is legitimate: I wait for you to release a resource. All I've done here is release the lock you think is erroneous, but perhaps it's another goroutine's job to do that, and from looking at your code it's really not possible to know that. You'd need some magical whole-program analysis, possibly even the solution to the halting problem, to know statically when a lock call is erroneous. Even dynamically, I think it's almost impossible to get it right every time. Unfortunate as deadlocks are, they're just bugs of a different flavor, and need to be debugged using any tool that works. In this case, I don't think vet is the right tool. |
Fair enough.
I guess one of the nice things about Go is that it makes it easier to reason about concurrent programs. Being able to detect a case where a thread holds a lock, and is blocked on itself would be really helpful. |
Closing but reopen if there's something I'm missing. |
This (single threaded program) will never work:
But instead of getting an error, panic, data race with the race detector, the program just hangs forever. It would be nice if there was some way to detect and warn about this obviously incorrect program, besides just hanging forever.
The text was updated successfully, but these errors were encountered: