[concurrency-interest] OpenJDK Project Loom - threads are not ideal mental tool

Ron Pressler ron.pressler at oracle.com
Thu Oct 26 14:19:20 EDT 2017

Hi. I wrote the Loom proposal.

Concurrency and parallelism are very different things. Concurrency is the problem of scheduling multiple _competing_ domain problems (e.g., servicing a transaction request from a user) onto some bounded set of computational resources; parallelism is the problem of optimally employing a set of computational resource to _cooperate_ on solving a single domain problem. Project Loom is first and foremost concerned with addressing the first (concurrency) and not the second (for which Java streams are likely a better solution). Concurrency is an important problem that is worth addressing, as motivated by the issues expressed in the beginning of the proposal; parallelism is simply not within the scope of this particular project. Having said that, the availability of delimited continuations may assist parallelism as well, and they can certainly help implementing dataflow graphs — those, however, will be left to third-parties, at least in the initial delivery of Project Loom.


On October 26, 2017 at 4:52:06 PM, Alexei Kaigorodov (alexei.kaigorodov at gmail.com) wrote:

From Loom Proposals:  

This is a sad case of a good and natural abstraction being abandoned in  
favor of a less natural one [asynchronous task], which is overall worse in  
many respects, merely because of the runtime performance characteristics of  
the abstraction.  

Well, "natural" may have at least two meanings. First, natural for the  
brains of human beings, and natural from mathematical point of view, and  
that meanings do not always agree. Say, Roman digits are more natural for  
low-skilled persons than Hindu–Arabic numerals, while the last is more  
natural mathematically. And being more natural mathematically always results  
in being more performant. Can you imagine a computer working in Roman  
numerals? Its cost and performance?  

So, if an abstraction is less performant, it should be examined against  
mathematical naturality. The main drawback of thread is, of course, the size  
of stack memory, and the proposed project is going to fix it. But there are  
other performance problems, which the project is not going to solve.  
Consider a program for copying a file:  

for (;;) {  
buff = input.read();  
if (buff == null) break;  

Reading and writing of each buffer is done sequentially (which is natural  
for human brain), while they could be done in parallel. But expressing this  
parallelism using threads would make thread-based program as complex as  
asynchronous implementation.  

The program representation which allows maximal parallelism is a dataflow  
graph. A thread represents a sequence in that graph, usually a cycle. Of  
course, each graph can be represented as a set of sequences (threads), but  
the thread representation has (at least) two problems. First is that  
elements of the sequence are executed sequentially, as pointed above.  
Second, decomposition of the graph into threads can be done in many  
variants. And the variant chosen by a programmer could be suboptimal, or  
become sо during the evolution of the program.  

So in order to support both brain and mathematics naturalities, I'd propose  
to develop following tools:  
- a compiler from thread representation to asynchronous (dataflow)  
- graphical editor and debugger who works with graph representation  
- a decompiler to convert graph representation into thread representation,  
which accepts user's advices how to split graph into threads.  

Sent from: https://urldefense.proofpoint.com/v2/url?u=http-3A__jsr166-2Dconcurrency.10961.n7.nabble.com_&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=-kUDHxC1IVB_ypN88uP5I0zEdrgC5UAi06w1pnrnunw&m=PweXYYVC_WnNu_wy-6J-6huh6rsBxDKguogCD-V57eU&s=lzVWOXrM-0mON4FCZKKZokTu-SdHL0UUNRU5VmVnYtU&e=  
Concurrency-interest mailing list  
Concurrency-interest at cs.oswego.edu  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20171026/38bf325b/attachment.html>

More information about the Concurrency-interest mailing list