Project Loom presentation at BangaloreJUG

Remi Forax forax at
Fri Dec 20 12:34:09 UTC 2019

Using a Blocking Queue or using your own queue ?


----- Mail original -----
> De: "Nawazish Khan" <md.nawazish.khan at>
> À: "Alan Bateman" <Alan.Bateman at>
> Cc: "loom-dev" <loom-dev at>
> Envoyé: Vendredi 20 Décembre 2019 13:27:19
> Objet: Re: Project Loom presentation at BangaloreJUG

> 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,
> On Wed, Dec 18, 2019 at 2:19 PM Alan Bateman <Alan.Bateman at>
> 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("", 7777);
>> }
>> A virtual thread executing this code will likely park twice when inside
>> the synchronized block, once to resolve "" 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

More information about the loom-dev mailing list