Project Loom presentation at BangaloreJUG

[Nawazish Khan]

Can anybody help me coming up with a contrived example of running a
producer-consumer pair in their own virtual threads, but on a *single
threaded* executor (schedular). Thanks in advance.

Sincerely,
MNK

On Wed, Dec 18, 2019 at 2:19 PM Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 17/12/2019 22:08, Volkan Yazıcı wrote:
> > [To the best of my knowledge,] pinning a carrier thread means that the
> > fiber will block the thread. In the current prototype, holding a
> > monitor is still a blocking operation.
> >
> Yes, and here's a simple example:
>
> synchronized (lock) {
>      Socket s = new Socket("pluto.com", 7777);
> }
>
> A virtual thread executing this code will likely park twice when inside
> the synchronized block, once to resolve "pluto.com" to a network
> address, the second when trying to establish the TCP connection to the
> remote host. Virtual threads that park while holding monitors will pin
> the underlying carrier thread, this just means it's not available to
> help other virtual threads that waiting to continue. It's a limitation
> that we want to go away in the medium-to-long term of course.
>
> The system property for the command line that I included in the other
> mail was just a diagnostic option to help track down cases like this.
> The output is a stack trace where the frames holding monitors are
> highlighted with a count of the number of monitors held. A good
> discussion for a meet-ups would be to identify cases like this in your
> code and to see how easy it would be replace with j.u.concurrent locks.
>
> -Alan
>