The core concept of structured concurrency is that when control splits into concurrent tasks that they join up again. If a “main task” splits into several concurrent sub-tasks scheduled to be executed in fibers then those fibers must terminate before the main task can complete.
The main benefit of structured concurrency is abstraction. A caller of a method that is invoked to do a task should not care if the method decomposes the task and schedules a million fibers. When the method completes, any fibers scheduled by the method should have terminated.
More information:
Nathaniel J. Smith: Notes on structured concurrency, or: Go statement considered harmful
Martin Sustrik: Structured Concurrency
Current prototype
In Project Loom, a prototype API has been developed called FiberScope that is a scope in which fibers are scheduled. Here is a basic example:
try (var scope = FiberScope.cancellable()) {
var fiber1 = scope.schedule(task);
var fiber2 = scope.schedule(task);
}
A thread or fiber enters a scope by calling the FiberScope.cancellable method (we will explain cancellation later). It exits the scope when the code in the block completes and any fibers scheduled in the scope have terminated. The example schedules two fibers. The thread/fiber executing the above code may have to wait (in the FiberScope’s close method) until the two fibers have terminated.
FiberScopes can be nested, consider the following:
try (var scope1 = FiberScope.cancellable()) {
scope1.schedule(task);
try (var scope2 = FiberScope.cancellable()) {
scope2.schedule(task);
}
scope1.schedule(task);
}
In this example, a thread or fiber enters scope1, schedules a fiber, then enters scope2 where it schedules a fiber in that scope. The execution cannot exit scope2 until the fiber scheduled in that scope terminates. When it exits, it is back in scope1. It cannot exit scope1 until the two fibers scheduled in that scope have terminated.
Structured concurrency leads naturally to trees of tasks. Consider the following method x that schedules two fibers to execute foo and bar. The code in foo and bar each schedule two fibers.
void x() {
try (var scope1 = FiberScope.cancellable()) {
var fiber1 = scope1.schedule(() -> foo());
var fiber2 = scope1.schedule(() -> bar());
}
}
void foo() {
try (var scope2 = FiberScope.cancellable()) {
scope2.schedule(() -> task());
scope2.schedule(() -> task());
}
}
void bar() {
try (var scope3 = FiberScope.cancellable()) {
scope3.schedule(() -> task());
scope3.schedule(() -> task());
}
}
fiber1 is scheduled in scope1. It enters scope2 and schedules two fibers. It exits scope2 (and returns to scope1) when the two fibers terminate. fiber2 is scheduled in scope1. It enters scope3 and schedules two fibers. It exits scope3 (and returns to scope1) when the two fibers terminate. The thread or fiber executing will not exit scope1 until fiber1 and fiber2 have terminated.
As an escape hatch, the FiberScope API defines the detached() method to return a scope which can be used to schedule fibers that are intended to outline the context where they are initially scheduled.