Add a thread-safe Random implementation (for Data streams monitoring)#3130
Conversation
d3847e2 to
2a31940
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
We have another implementation in SpanIdGenerator, and it's different than this one:
[ThreadStatic]vsThreadLocal<T>(which one should we use?)- on .NET Framework, we use one static
Randomto seed each newRandominstance to work around an issue with low clock resolution
We should probably consolidate the code with that one as well.
EDIT: never mind, I missed the global random used for seeds in the new implementation 🤦🏽♂️
kevingosse
left a comment
There was a problem hiding this comment.
LGTM but you should use it in the SpanIdGenerator as well (it's pretty much the same algorithm as far as I can tell)
As much as possible I'd recommend using |
2a31940 to
6ccc6c3
Compare
This comment has been minimized.
This comment has been minimized.
6ccc6c3 to
e289786
Compare
This comment has been minimized.
This comment has been minimized.
SpanIdGenerator was a thin wrapper around essentially the same implementation, so converted it to a simple static method that uses ThreadSafeRandom implicitly The downside to this is we can't create a `SpanIdGenerator` with a specific seed any more. But as far as I can tell we were never doing that anyway, even in tests, so I think this is simpler
e289786 to
8a14996
Compare
Benchmarks Report 🐌Benchmarks for #3130 compared to master:
The following thresholds were used for comparing the benchmark speeds:
Allocation changes below 0.5% are ignored. Benchmark detailsBenchmarks.Trace.AgentWriterBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.AppSecBodyBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.AspNetCoreBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.DbCommandBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.ElasticsearchBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.GraphQLBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.HttpClientBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.ILoggerBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.Log4netBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.NLogBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.RedisBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.SerilogBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.SpanBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.TraceAnnotationsBenchmark - Same speed ✔️ Same allocations ✔️Raw results
|
Code Coverage Report 📊✔️ Merging #3130 into master will not change line coverage
View the full report for further details: Datadog.Trace Breakdown ✔️
The following classes have significant coverage changes.
The following classes were added in #3130:
1 classes were removed from Datadog.Trace in #3130 View the full reports for further details: |
Summary of changes
Adds a thread-safe random implementation.
Reason for change
Required by data streams monitoring. The Debugger already had its own implementation, so centralised, hardened, and defaulted to the built-in version in .NET 6.
Implementation details
ThreadLocalRandom, and a "global" random for seeding the thread-local ones.Test coverage
Yeah... should probably be some...
Other details
Required for data streams monitoring