binder: synchronize in-use stream updates and replace AtomicInteger with primitive int #12458
Conversation
…ronizing in-use updates Previously, concurrent calls to newStream() and unregisterInbound() could both update numInUseStreams and invoke transportInUse() in conflicting order, leading to inconsistent listener state. This change synchronizes updates and only notifies the listener on transitions between 0 and >0. Fixes grpc#10917
|
I’m considering adding a unit test for updateInUseStreamsIfNeed() (with VisibleForTesting annotation) |
| @GuardedBy("this") | ||
| void notifyTerminated() { | ||
| if (numInUseStreams.getAndSet(0) > 0) { | ||
| if(numInUseStreams > 0) { |
There was a problem hiding this comment.
Please format this code according to the style guide: https://google.github.io/styleguide/javaguide.html I recommend the https://github.com/google/google-java-format tool
| if (inbound.countsForInUse() && numInUseStreams.decrementAndGet() == 0) { | ||
| clientTransportListener.transportInUse(false); | ||
| } | ||
| updateInUseStreamsIfNeed(inbound.countsForInUse(), -1); |
There was a problem hiding this comment.
Please see "A note on synchronization" at the top of BinderTransport.java. Note that unregisterInbound() is called from Inbound.java's synchronized closeAbnormal() and deliverSuffix() methods (via unregister()) Is your proposed lock acquisition order safe or does it risk deadlock?
2 participants
Fixes a race between
newStream()andunregisterInbound()that could cause inconsistenttransportInUse()notifications. The updates tonumInUseStreamsare now synchronized viaupdateInUseStreamsIfNeed(), ensuring listener state remains accurate.Also replaced
AtomicIntegerwith a primitiveintsince synchronization makes atomic operations unnecessary.Fixes #10917