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

Ensure safe access to global rand.Rand #5815

Closed
wants to merge 4 commits into from

Conversation

pkwarren
Copy link
Contributor

Update rand.Rand usage to add locking around a global rand.Rand instance, which is not safe for concurrent access by multiple goroutines.

Fixes #5814.

Copy link

codecov bot commented Sep 12, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 84.5%. Comparing base (a475ee2) to head (c11e20d).
Report is 4 commits behind head on main.

Additional details and impacted files

Impacted file tree graph

@@           Coverage Diff           @@
##            main   #5815     +/-   ##
=======================================
- Coverage   84.5%   84.5%   -0.1%     
=======================================
  Files        272     272             
  Lines      22766   22778     +12     
=======================================
+ Hits       19251   19258      +7     
- Misses      3172    3177      +5     
  Partials     343     343             

see 11 files with indirect coverage changes

Update rand.Rand usage to add locking around a global rand.Rand
instance, which is not safe for concurrent access by multiple
goroutines.

Fixes open-telemetry#5814.
CHANGELOG.md Outdated Show resolved Hide resolved
Co-authored-by: Damien Mathieu <[email protected]>
@MrAlias
Copy link
Contributor

MrAlias commented Sep 13, 2024

Thank you for the contribution. I've created #5819 as a replacement for this. It makes a more systemic change to the structure of random number generation in the exemplar code base. I'm going to close this as it seems to be superseded by that PR, please re-open if this is done in error.

@MrAlias MrAlias closed this Sep 13, 2024
@pkwarren pkwarren deleted the issue-5814 branch September 13, 2024 19:32
MrAlias added a commit that referenced this pull request Sep 16, 2024
Instead of using a global random number generator for all `randRes`,
have each value use its own. This removes the need for locking and
managing concurrent safe access to the global. Also, the field, given
the `Reservoir` type is not concurrent safe and the metric pipeline
guards this, does not need a `sync.Mutex` to guard it.

Supersedes #5815 
Fix #5814

### Performance Analysis

This change has approximately equivalent performance as the existing
code based on existing benchmarks.

```terminal
goos: linux
goarch: amd64
pkg: go.opentelemetry.io/otel/sdk/metric
cpu: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz
                           │   old.txt   │              new.txt               │
                           │   sec/op    │   sec/op     vs base               │
Exemplars/Int64Counter/8-8   14.00µ ± 3%   13.44µ ± 4%  -3.98% (p=0.001 n=10)

                           │   old.txt    │             new.txt              │
                           │     B/op     │     B/op      vs base            │
Exemplars/Int64Counter/8-8   3.791Ki ± 0%   3.791Ki ± 0%  ~ (p=1.000 n=10) ¹
¹ all samples are equal

                           │  old.txt   │            new.txt             │
                           │ allocs/op  │ allocs/op   vs base            │
Exemplars/Int64Counter/8-8   84.00 ± 0%   84.00 ± 0%  ~ (p=1.000 n=10) ¹
¹ all samples are equal
```
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Missing lock around rng access in rand.go
3 participants