Data Race on the field ''items''

[yanke-xu]

During our research on non-blocking concurrency bugs in gRPC, we discovered a potential Data Race in the program. Specifically，there are two confilicting operations on the field "items", where

the read operation at：.../grpc/internal/wrr/random.go:90, and the write operation at：.../grpc/internal/wrr/random.go:86

I don't know whether it is accurate, so I 'm looking forward to your reply.

[dfawley]

Can you provide a reproduction sample for this?

This would only happen if the wrr state is being logged while also being changed, so wouldn't be critical for correctness. Adding a rw.mu.RLock(); defer rw.mu.RUnlock() to the top of (*randomWRR).String would also prevent this.

[github-actions[bot]]

This issue is labeled as requiring an update from the reporter, and no update has been received after 6 days. If no update is provided in the next 7 days, this issue will be automatically closed.

[yanke-xu]

Is it possible for the two statements to be executed at the same time? If so, adding a rw.mu.RLock(); defer rw.mu.RUnlock() to the top of *randomWRR).String is necessary.

[arvindbr8]

Add() is always called as part of constructing the WRR object and never concurrently. Also turns out Next() is never called concurrently either. I started the PR (#5970) started out to avoid the race when accessing WRR.items in String(), but the mutex can be avoided all together for random WRR.