Thoughts on virtual thread pinning caused by classic synchronization

[Alan Bateman]

On 08/08/2021 10:54, Thilo-Alexander Ginkel wrote:
> Hello everyone,
>
> while experimenting with Loom (build 17-loom+7-342) we noticed that there
> are a couple of JDK classes (such as PushbackInputStream, file channels,
> ...) that rely on classic synchronization and thus cause virtual threads to
> be pinned. Third-party libraries exhibit similar behavior.
>
> Are you planning to eventually support classic "synchronized" with Loom or
> do libraries (as well as the JDK) need to migrate to lock-based concurrency?
>
The expectation is that Java monitors will eventually be re-implemented. 
There has been some early exploration and prototyping but we expect to 
have the limitation for at least a first release. In the mean-time, and 
where feasible and impactful, the implementation of several APIs have 
been changed to use j.u.concurrent locks so that virtual threads can 
park gracefully when doing blocking I/O. Examples include the network 
channels, sockets, and http/https protocol handlers.

The java.io APIs are problematic as they have used synchronization since 
JDK 1.0/1.1. In most cases the synchronization is not specified and not 
enforced consistently. In other cases there is a lock object exposed as 
a protected field for sub-classes. In general, most of these APIs should 
not need synchronization but there are a few exceptions (PrintStream 
intended to be written too by concurrent threads, async close, cases 
where the underlying transport is packet based, and a few 
security-sensitive scenarios where corrupting the stream is a concern). 
So we have to proceed with caution. The approach that we've taken is to 
use j.u.c. locks when not sub-classed or when sub-classes by trusted/JDK 
classes. There is still a risk that there is code in the wild that makes 
assumptions on how synchronizes on the stream but I don't think we can 
do anything about that. At some point, and probably over several 
releases, we will need to address the technical debt in this area and 
gradually remove the often-broken and unspecified synchronization.

You mentioned PushbackInputStream and you shouldn't have an issue there, 
unless you are wrapping something that is using synchronization. You 
also mentioned FileChannel - if you have concurrent threads accessing a 
file channel then they will probably be using the positional read/write 
methods that are designed to support concurrent access to different 
parts of a file.

-Alan