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

Alexei Kaigorodov alexei.kaigorodov at gmail.com
Thu Oct 26 09:50:34 EDT 2017


>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;
   output.write(buff);
}

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)
representation
 - 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: http://jsr166-concurrency.10961.n7.nabble.com/


More information about the Concurrency-interest mailing list