Project Loom presentation at BangaloreJUG
forax at univ-mlv.fr
forax at univ-mlv.fr
Fri Dec 20 13:58:27 UTC 2019
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
More information about the loom-dev
mailing list