A common programming mistake in Go is to add an early return statement in a critical section and then to forget to release the mutex. Usually the unlock operation can be deferred so that it runs automatically, but there are times when the critical section does not extend to the end of the function so defer cannot be used. It would be interesting to see how many mistakes a checker in the analysis framework might catch. (A quick experiment in x/tools caught only the one instance that I was training it on.)

The notion of "critical section" could be generalized to other control flow problems. For example, some long functions (example) are structured to have a single return statement and a comment saying "don't return before the end!". This region can be thought of as a "critical section of no return" that is "unlocked" immediately before the final return statement. Similarly, a function that opens a file and then closes it before returning should probably close it on all paths, making a "critical section of an open file". Ideally a checker would allow the user to define pairs of lock/unlock operation using some kind of annotation mechanism.