Skip to content
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

Jump to bottom

sync: RWMutex non-reentrant rlock -race check #35138

Closed
av-elier opened this issue Oct 24, 2019 · 3 comments
Closed

sync: RWMutex non-reentrant rlock -race check #35138

av-elier opened this issue Oct 24, 2019 · 3 comments
Labels
FeatureRequest FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Backlog

Comments

@av-elier
Copy link

What version of Go are you using (go version)?

$ go version
go version go1.12.1 linux/amd64

What did you do?

Misused RLock: https://play.golang.com/p/-7UFH11FDRV

RLock
It should not be used for recursive read locking; a blocked Lock call excludes new readers from acquiring the lock.

What did you expect to see?

I want a -race mode to detect reentrant RLock calls even if deadlock is not yet happened.

I want to propose to add this check to race detector. I am not familiar with how exactly race detector works. But it seems to me that it should be possible to save RLock/RUnlock calls for each goroutine in race mode, and when pattern (RLock,RLock,RUnlock,RUnlock) apear in the order of calls - it's a sign that RLock is misused.

Is it a good idea, to add a check for this?
@av-elier av-elier changed the title RWmutex non-reentrant rlock -race check RWMutex non-reentrant rlock -race check Oct 24, 2019
@dmitshur dmitshur changed the title RWMutex non-reentrant rlock -race check sync: RWMutex non-reentrant rlock -race check Oct 24, 2019
@dmitshur dmitshur added FeatureRequest NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Oct 24, 2019
@dmitshur dmitshur added this to the Backlog milestone Oct 24, 2019
@dmitshur
Copy link
Contributor

/cc @mdempsky @dvyukov FYI, in case you have thoughts on this.

@dvyukov
Copy link
Member

dvyukov commented Oct 24, 2019

This is undetectable. Unfortunately. Go does not have mutexes, only semaphores. So the check will have false positives.
But otherwise tsan runtime generally have most things ready for deadlock detection on mutexes:
https://github.com/llvm-mirror/compiler-rt/blob/master/include/sanitizer/tsan_interface.h#L27-L105

@rsc
Copy link
Contributor

rsc commented Oct 24, 2019

What Dmitry means is that in Go, ownership of a mutex is not tied to a specific goroutine. It is OK to do code like:

m.RLock()
go work() // does m.RUnlock when done
m.RLock()

and that's not a deadlock. Drop the R's and it is still not a deadlock. But a deadlock detector that assumes lock ownership is tied to a thread/goroutine would report it as a deadlock.

I suppose that back to back RLock with no scheduling event between them might be detectable but that's never the interesting thing to detect.

Closing because this is not detectable.

@rsc rsc closed this as completed Oct 24, 2019
@golang golang locked and limited conversation to collaborators Oct 23, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FeatureRequest FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
Backlog
Development

No branches or pull requests
5 participants
@rsc @dvyukov @dmitshur @av-elier @gopherbot