An Analogy

[Ron Pressler]

I would think about this differently. There is no important, essential, difference between virtual threads and OS threads. They implement the same thread abstraction that and both employ similar algorithms that ultimately schedule user code to run on a processing core or have it taken off it to run other code. The main difference is that one is a subprogram of the OS kernel, and the other is a subprogram of the Java runtime. OS threads are no more “real” or do no more “actual work” than virtual threads. They're both software constructs that create an abstraction, or illusion, that virtualises actual resources, such as the CPU.

So to keep with your analogy, having virtual threads is just having access to more tellers. Instead of waiting for one of a small set, every customer who walks into the bank (up to some very large number), immediately gets their own teller.

— Ron

On 19 Jul 2022, at 19:34, eric at kolotyluk.net<mailto:eric at kolotyluk.net> wrote:

I am hoping this is an apt analogy, so please correct me if it is wrong…

Before Loom, concurrency was like going to a bank with a fixed number of tellers, where each teller had a line of customers.


  1.  In Java terms, a teller is like Platform Thread
  2.  Generally, it would take time to process each customer, say an average of 5 minutes
  3.  Sometimes, a customer would block the process, such as the teller needed to make a phone call to get some information
  4.  No work is performed, while the teller is blocked waiting, and consequently the entire line is blocked


After Loom, concurrency is like going to a bank with more modern policies and procedures


  1.  In Java terms, a teller is still like a Platform Thread, but has the ability to park a customer
  2.  Generally, it still takes time to process each customer, say an average of 5 minutes
  3.  Sometimes, a customer would block the process, such as the teller needed some information before proceeding…
     *   The teller sends a text message or emails to get the necessary information
     *   The teller asks the customer to be seated, and as soon the information is available, they will be the next customer processed by the first available teller
     *   The teller starts processing the next customer in line
     *   This is analogous to a parked Virtual Thread, where the teller is like a Platform Thread, and the customer is like a Virtual Thread
  4.  Concurrency is increased, by better policies and procedures in dealing with blocking operations


Yes, this is very simplistic, but intentionally so to try to expose what is so great about Virtual Threads.

Cheers, Eric

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20220720/068d0405/attachment.htm>