Skip to content
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

fix ConnPool race in newConn #2885

Merged
merged 2 commits into from Feb 14, 2024

Conversation

OlegStotsky
Copy link
Contributor

@OlegStotsky OlegStotsky commented Feb 5, 2024

Currently there is a race in newConn. This means that any code that uses this client will fail tests with -race flag enabled. This PR fixes this.

@OlegStotsky
Copy link
Contributor Author

@ofekshenawa please take a look

@Aden-Q
Copy link

Aden-Q commented Feb 6, 2024

@OlegStotsky You should mention my issue here (if you saw it). And I don't think it's the correct way to fix the issue. Even though it can protect the variable to be mutated while being read. There still can be interleaving execution flows, causing some errors on the semantic level (for example, read the value in one goroutine, afterwards it is updated by another goroutine. In which case there will not be data race, but there is a semantic error). I think we need to we protect the full scope of the critical section, instead of doing: lock-unlock, then lock-unlock again.

@OlegStotsky
Copy link
Contributor Author

@Aden-Q I've added another check after we acquire the mutex again. Should be correct now.

@OlegStotsky
Copy link
Contributor Author

@vmihailenco could you take a look please

@ofekshenawa ofekshenawa linked an issue Feb 14, 2024 that may be closed by this pull request
@ofekshenawa ofekshenawa merged commit 36bab9c into redis:master Feb 14, 2024
8 of 9 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[BUGS] data race in connection pool management
4 participants