Use Case

sync.RWMutex must not be used for recursive read locking, as this possibly creates opportunities for deadlocks. This is well documented at RWMutex as well as at RWMutex.RLock itself. However, I think there is still a high risk for misuse, as it is sometimes not immediately obvious where read locks are acquired in large code bases. Refactorings can also quickly lead to accidental recursive read locks.

Feature Request

It would be very useful to me, if go vet could find recursive read locks and warn me about them. I find that recursive read locks are very hard to find by other means, while they often lead to critical and hard to reproduce bugs.

Example

Here is a simple example of a recursive read lock (playground) and a suggested output of go vet :

$ cat main.go
package main

import (
        "fmt"
        "sync"
)

func main() {
        lock := sync.RWMutex{}

        lock.RLock()
        defer lock.RUnlock()
        fmt.Println("First read lock acquired.")

        lock.RLock()
        defer lock.RUnlock()
        fmt.Println("Second read lock acquired.")
}

$ go vet main.go
./main.go:15:7: call of RLock is recursive: RLock was already called at ./main.go:11:7  

Comment From: seankhliao

one of the bars for inclusion in cmd/vet is that it has to be a frequent issue. how common is this in real world code. please show examples across the ecosystem.