Re: Object-based monitors vs Lock based-monitors for JDK 17+

Alan Bateman via Concurrency-interest <[email protected]> Wed, 6 Oct 2021 08:58:58 +0100
Newsgroups gmane.comp.java.jsr.166-concurrency
Message-ID <[email protected]>
On 05/10/2021 09:17, Andrew Haley via Concurrency-interest wrote:
> :
>> Also, which are preferable when using Loom's virtual threads? I recall
>> reading that there may be limitations around Object-based monitors and
>> virtual threads, such as blocking the carrier thread.
> Quite. If you expect to do anything that might block, don't use a
> built-in monitor. If you expect a lot of threads to be contending
> for some resource don't use a built-in monitor.
>

Just to add that it is likely that the initial preview of virtual 
threads will have the limitation that parking while holding a monitor 
will prevent the underlying "carrier" thread from being released to do 
other work. So there may be a quality of implementation issue for cases 
where code does a blocking I/O operation while holding a monitor. 
Changing these cases to use a j.u.c lock can be used to workaround the 
limitation in the short term. This isn't saying that every usages of 
monitors needs to change of course.

-Alan