Thoughts on virtual thread pinning caused by classic synchronization
Alan Bateman
Alan.Bateman at oracle.com
Sun Aug 8 13:35:04 UTC 2021
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
More information about the loom-dev
mailing list