-
Notifications
You must be signed in to change notification settings - Fork 97
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
Use RWLock in prometheus metrics #331
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
During our team sync today, we talked of adding tests around concurrency and race conditions for this change.
The new go test -tags race --race --timeout 60s -v ./...
|
|
||
go func(j int) { | ||
p.Increment("race") | ||
}(i) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh. Heh. A previous iteration of this used p.Count("race", j)
which needed i
to be passed in to avoid triggering the wrong race condition. Doesn't need to be any more. 😶
A mutex is used in the prometheus metrics implementation and in honeycombio#324 was used the lock when using the different metrics types. This PR switches the mutex type to a RWLock to allow concurrent retrieving of metrics from the map. Co-authored-by: Robb Kidd <robbkidd@honeycomb.io>
Which problem is this PR solving?
A mutex is used in the prometheus metrics implementation and in #324 was used the lock when using the different metrics types. This PR switches the mutex type to a RWLock to allow concurrent retrieving of metrics from the map.
Register is the only place where a write lock is required.
Short description of the changes
RLock/RUnlock
when using the different metric types