Thread by @nipafx

#ProjectLoom's virtual threads will make high performance in concurrent systems attainable with much simpler code. But Loom aims for even more and wants to make the code clearer and more robust by introducing *structured concurrency*.

Here's what that's all about. 🧵

Important: This is about concurrency, not parallelism. See yesterday's thread 👇🏾 for a more detailed distinction, but the gist is that concurrency is about processing lots of tasks that the environment throws at your system at the same time, ideally with high throughput.

https://twitter.com/nipafx/status/1472906786650959884

Concurrency code is often unstructured:

* splitting and joining concurrent subtasks in different methods/classes
* little support to compose error-handling, cancellation, … across subtasks
* threading structure is opaque to the runtime, which only sees independent threads
* …

That makes it hard for devs to write and maintain concurrent code. And debugging/monitoring suffers as well because the runtime doesn't see the structure.

The underlying problem is that the building blocks are too general and technical - they lack semantics.

Software development was in that situation before, most notably with GOTO et al vs structured programming (en.wikipedia.org/wiki/Structure…). GOTO lead to endless spaghetti, so structured programming constructs that were both more *limited* and more *semantic*.

Martin Sústrik introduced the same idea for concurrency in 250bpm.com/blog:71/ :

"Structured concurrency is similar to […] structured programming […]. [It] prevents random jumping around the codebase and instead structures the program as a set of nested code blocks."

That inspired Project Loom's approach - an API that:

* makes it easy to start and join subtasks in the same block
* prevents threads from escaping the scope
* allows easy error-handling across them
* captures task/subtask hierarchy for easier debugging and monitoring

The draft JEP (openjdk.java.net/jeps/8277129) proposes an API that can already be experimented with in the Loom EA builds (jdk.java.net/loom/). If you can gather some practical experience (e.g. refactoring a project), sharing it on the mailing list would be very welcome.

🏁

PS: The latest Inside Java Newscast () discusses this topic in a bit more detail. If you want a lot more detail check the JEP (👆🏾), Sústrik's post (👆🏾👆🏾) and, if you still don't have enough, this one by @vorpalsmith: vorpus.org/blog/notes-on-…