Project Loom presentation at BangaloreJUG

[forax at univ-mlv.fr]

import java.util.concurrent.ArrayBlockingQueue; 
import java.util.concurrent.BlockingQueue; 
import java.util.concurrent.Executors; 

public class ProducerConsumer { 
private static void produce(BlockingQueue<String> queue) { 
try { 
for(;;) { 
queue.put("hello "); 
System.out.println("produce " + Thread.currentThread()); 

Thread.sleep(200); 
} 
} catch (InterruptedException e) { 
throw new AssertionError(e); 
} 
} 

private static void consume(BlockingQueue<String> queue) { 
try { 
for(;;) { 
var message = queue.take(); 
System.out.println("consume " + Thread.currentThread() + " received " + message); 

Thread.sleep(200); 
} 
} catch (InterruptedException e) { 
throw new AssertionError(e); 
} 
} 

public static void main(String[] args) { 
var queue = new ArrayBlockingQueue<String>(8192); 

// try (var scheduler = Executors.newFixedThreadPool(1)) { 
// var factory = 
//Thread.builder().virtual(scheduler).factory(); 
// try (var executor = 
//Executors.newUnboundedExecutor(factory)) { 
// executor.submit(() -> produce(queue)); 
// executor.submit(() -> consume(queue)); 
// } 
// } 

var scheduler = Executors.newFixedThreadPool(1); 
Thread.builder().name("producer").virtual(scheduler).task(() -> produce(queue)).build().start(); 
Thread.builder().name("consumer").virtual(scheduler).task(() -> consume(queue)).build().start(); 
} 
} 

with Alan code, i don't think you can name the virtual threads, 
mine is a little more brutal, i create the virtual threads outside of a thread pool, but i can name them. 

Rémi 

> De: "Nawazish Khan" <md.nawazish.khan at gmail.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Alan Bateman" <Alan.Bateman at oracle.com>, "loom-dev"
> <loom-dev at openjdk.java.net>
> Envoyé: Vendredi 20 Décembre 2019 14:24:58
> Objet: Re: Project Loom presentation at BangaloreJUG

> Thanks Alan, I initially wanted to use SynchronousQueue. But a BlockingQueue
> from the core lib would be ok.

> On Fri, Dec 20, 2019 at 6:34 PM Remi Forax < [ mailto:forax at univ-mlv.fr |
> forax at univ-mlv.fr ] > wrote:

>> Using a Blocking Queue or using your own queue ?

>> Rémi

>> ----- Mail original -----
>>> De: "Nawazish Khan" < [ mailto:md.nawazish.khan at gmail.com |
>> > md.nawazish.khan at gmail.com ] >
>>> À: "Alan Bateman" < [ mailto:Alan.Bateman at oracle.com | Alan.Bateman at oracle.com ]
>> > >
>>> Cc: "loom-dev" < [ mailto:loom-dev at openjdk.java.net | loom-dev at openjdk.java.net
>> > ] >
>> > 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,
>> > MNK

>>> On Wed, Dec 18, 2019 at 2:19 PM Alan Bateman < [ mailto:Alan.Bateman at oracle.com
>> > | 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(" [ http://pluto.com/ | pluto.com ] ", 7777);
>> >> }

>> >> A virtual thread executing this code will likely park twice when inside
>>>> the synchronized block, once to resolve " [ http://pluto.com/ | 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