Make access to ArrayDeque synchronized#7027
Conversation
|
|
ArrayDeque specifies that: > Array deques ... are not thread-safe; in the absence of external > synchronization, they do not support concurrent access by multiple > threads. `marshalerPool` is concurrently added to by the OkHttp threadpool without synchronization, along with all threads that end spans (with synchronisation in `SimpleSpanProcessor.exportLock`, which is not used to synchronize with the OkHttp threadpool). Just making the ArrayQueue synchronous internally removes all need to worry about upstream locks. Fixes open-telemetry#7019
df49e28 to
6d32714
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #7027 +/- ##
=========================================
Coverage 89.95% 89.95%
Complexity 6636 6636
=========================================
Files 745 745
Lines 20010 20015 +5
Branches 1962 1962
=========================================
+ Hits 17999 18004 +5
Misses 1415 1415
Partials 596 596 ☔ View full report in Codecov by Sentry. |
| public class SpanReusableDataMarshaler { | ||
|
|
||
| private final Deque<LowAllocationTraceRequestMarshaler> marshalerPool = new ArrayDeque<>(); | ||
| private final SynchronizedQueue<LowAllocationTraceRequestMarshaler> marshalerPool = |
There was a problem hiding this comment.
the same construct is also used in
did you consider just using a different queue implementation such as
ConcurrentLinkedDeque?
There was a problem hiding this comment.
Let's do this.
Also, this change is applicable to MetricReusableDataMarshaler and LogReusableDataMarshaler as well.
There was a problem hiding this comment.
did you consider just using a different queue implementation such as
ConcurrentLinkedDeque?
No, I didn't even remember ConcurrentLinkedDeque existed, and I'm not familiar with its guarantees and performance characteristics. Might well be a better and lighter option.
ArrayDeque specifies that:
marshalerPoolis concurrently added to by the OkHttp threadpool without synchronization, along with all threads that end spans (with synchronisation inSimpleSpanProcessor.exportLock, which is not used to synchronize with the OkHttp threadpool).Just making the ArrayQueue synchronous internally removes all need to worry about upstream locks.
Fixes #7019