-
Notifications
You must be signed in to change notification settings - Fork 7.3k
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
Replace use of synchronized in OkHttpCall with ReentrantLock #4297
Labels
Comments
It might be better to replace it with a compare and swap loop with an atomic? We're not guarding an operation, just performing creation where only a single instance can win. Plus the idea of contention here is near zero, and the cost of double allocation before a winner is determined is negligible. |
Thanks for the pointer - I'll take a look! |
qwexter
added a commit
to qwexter/retrofit
that referenced
this issue
Feb 21, 2025
Replace synchronized blocks with atomic compare-and-swap logic. It prevent virtual thread pinning and reduce contention. See square/okhttp#4297 for more details.
qwexter
added a commit
to qwexter/retrofit
that referenced
this issue
Feb 21, 2025
Replace synchronized blocks with atomic compare-and-swap logic. It prevent virtual thread pinning and reduce contention. See square#4297 for more details.
1 task
qwexter
added a commit
to qwexter/retrofit
that referenced
this issue
Feb 28, 2025
Replace synchronized blocks with atomic compare-and-swap logic. It prevent virtual thread pinning and reduce contention. See square#4297 for more details.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We use Retrofit in our backend, and I notice that
retrofit2.OkHttpCall
relies extensively onsynchronized(this)
, which can pin host threads (when using virtual threads). Would you be open to a PR replacing use ofsynchronized
here with use ofReentrantLock
?The text was updated successfully, but these errors were encountered: