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