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

Replace use of synchronized in OkHttpCall with ReentrantLock #4297

Open
bendb-instacart opened this issue Feb 4, 2025 · 2 comments
Open

Comments

@bendb-instacart
Copy link

We use Retrofit in our backend, and I notice that retrofit2.OkHttpCall relies extensively on synchronized(this), which can pin host threads (when using virtual threads). Would you be open to a PR replacing use of synchronized here with use of ReentrantLock?

@JakeWharton
Copy link
Collaborator

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.

@bendb-instacart
Copy link
Author

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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants