1

Structured concurrency:

a simple principle that states that when the flow of execution splits into multiple concurrent flows, they rejoin in the same code block.

Source

Based on this, let's assume I have something like below:

//can replace this with Virtual thread
public static void delegateTask() {
    Thread delegator = new Thread(new TaskDeligator());
    delegator.setName("TaskDeligatorThread");
    logger.info("Creating task delegator thread....which will register listeners");
    delegator.start();
}

Question 1: I have created a new child thread(TaskDeligatorThread) but did not finish/end/rejoin in the same code block i.e. the method delegateTask() - does this mean it's not following structured concurrency principle?

Question 2: There might be scenarios where Thread1 wants to delegate some task to a child thread (which Thread1 will create) and Thread1 doesn't need to wait for the output/completion of the child thread. In this case, again I will not finish/end/rejoin the child thread in the code block where the child thread was created. In these kind of scenarios how would I follow structured concurrency?

srock
  • 403
  • 1
  • 8
  • 17
  • 2
    My 2c is that if the code which creates the thread has no interest in whether it completes successfully, then structured concurrency is irrelevant. – tgdavies Jan 20 '22 at 01:34
  • Makes sense, @tgdavies. Would that be considered bad practice? Thanks – srock Jan 20 '22 at 18:51
  • It depends what the thread is doing. Perhaps there's some other way that failures are reported, or perhaps failure doesn't matter. It depends. – tgdavies Jan 20 '22 at 23:45

1 Answers1

1

The phrase "within the same code block" is a bit ambiguous.

Strictly speaking, your main method could open a StructuredExecutor and make it available to all code in your entire program, such that you're using the library support for structured concurrency but not really using structured concurrency. (This is roughly analogous to using for+switch to write spaghetti code that technically doesn't contain 'goto' but amounts to the same thing.)

Both of your examples do not follow the structured concurrency principle, because they involve forking off a task and abandoning it. You can potentially rework them to follow that principle by identifying a higher-level caller that really does depend on that task, and having that higher-level caller manage the StructuredExecutor. Alternatively, you might decide that you don't really want to follow this principle, either in general or in these cases.

The JEP doesn't really explain the concept of structured concurrency in detail, because its main focus is on how it could be supported in Java. If you'd like to understand the concept itself, I'd recommend reading one or both of the blog posts that it links to:

(Note: the former is a bit more technical, the latter a bit easier to read.)

ruakh
  • 175,680
  • 26
  • 273
  • 307
  • Thank for the blog posts, will take a look @ruakh. So is it that whenever we make use of listeners `java.util.EventListener` it will never be structured...even though the flow comes back after the listener is registered. In the background there is a thread which is alive and keeps listening for events. – srock Jan 20 '22 at 18:50
  • @srock: I'm not aware of any inherent reason that java.util.EventListener is incompatible with structured concurrency. But I definitely recommend that you read through the second blog post that I linked to (the one by Nathan J. Smith); I don't think I can answer your questions any better than you'll get by reading that post. (That post is arguably the definitive exposition of the concept.) – ruakh Jan 21 '22 at 22:27