-
Notifications
You must be signed in to change notification settings - Fork 897
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
GODRIVER-2533 Fix data race from NumberSessionsInProgress. #1085
GODRIVER-2533 Fix data race from NumberSessionsInProgress. #1085
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Atomic logic looks good!
mongo/integration/sessions_test.go
Outdated
select { | ||
case <-ctx.Done(): | ||
return | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This select
statement seems like it will block until the ctx.Done()
channel is closed and will never reach the call below. To get around that, either add a default
case or check if the context is done in the for
loop.
E.g.
for ctx.Err() == nil {
_ = mt.Client.NumberSessionsInProgress()
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm a little concerned about the busy waiting here as it occupies the CPU while waiting. Will this be an issue?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TIL about the anti-pattern of busy-waiting, thanks 🧑🔧 . I modified the test to only run each operation 5 times and used a channel to sync the goroutines' execution as opposed to a context. Note that the test fails now only about 75% of the time when checkedOut
is not atomically accessed (as opposed to closer to 95% of the time with the previous design). I think that's fine, though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think short busy-wait loops in tests that are trying to exercise a specific non-deterministic behavior are probably OK, but I do think the "run N times" loops are a good way to achieve that also. I left some suggestions about possible ways to further improve the reliability of the tests in my subsequent review.
@matthewdale thank you for catching that the test was not actually running the functions 😮💨 . Should be fixed now; I also used a |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good 👍
@matthewdale thanks. Removed channel, increased iteration count to 100, and added a 100µs sleep. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
GODRIVER-2533
Fixes data race in
session.Pool
by switchingcheckedOut
from anint
to an atomically-accessedint64
. Adds a regression test for the data race.