A question to the community: IO inside synchronized methods/blocks

[Ron Pressler]

Fibers would eventually need to support ‘native’ VM synchronization via synchronized/Object.wait. However, we’re exploring not supporting those in the first release. A contended synchronized block or an Object.wait would — instead of just suspending the fiber — would suspend the underlying scheduler worker thread. This would not change the semantics of those operations, but would diminish the scalability benefit of using blocking IO APIs on fibers. Blocking IO protected by j.u.c (java.util.concurrent package) synchronization classes (locks and the like) would not be an issue.

To evaluate the viability of this approach, we’d like to know how common it is for application or library code to perform blocking IO inside synchronized methods/blocks. Please let us know how common this pattern is in the application code you write and in the libraries you use, and how onerous it would be to switch to using j.u.c constructs.

Thank you!

Ron