You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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.
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.
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: