Structured Concurrency, it seems to be some confusing term to me.
Before we talk about this term, I think will better to understand 'Concurrency' and
'Parallelism'.
Concurrency - As per my understanding, it is like one person doing more than 1 task.
What does it mean?
Does it mean that the same person is having multiple tasks at the same time?
Does it mean that the same person is doing multiple tasks at the same time?
It means, yes, the same person is having multiple tasks to do.
But it doesn't mean that the same person is taking actions on multiple tasks at the same time.
Obviously, no person can work on multiple tasks at the same moment, all requiring its same resource e.g. 'Brain'.
So a person does context switching or alternate between different tasks assigned, to show the progress in every task.
But that person will be working only on one task at a particular moment.
And a successful concurrency will be, if no task is corrupted due to other task with that person.
Same goes for Processor, a single processor does multiple tasks concurrently & does lot of context switching & it feels that all tasks are being done at the same time.
Will suggest to read more about Concurrency.
Parallelism - It is like multiple tasks being done by multiple people.
And, yes, here all people can continue to work on their respective tasks at the same time.
Same thing goes for Computers which have multiple cores allowing each core to work on
different task.
Will suggest to read more about this.
But what issue we are talking about here? In multithreading we start multiple threads to work
on multiple sub-tasks to get the main task done.
Our main task will be done successfully only when all its sub-tasks complete successfully.
So if any sub-task fails then we don't need other sub-tasks to continue but their threads are already out there which continue their processing & it becomes a concern-
a) If those sub-tasks cause side-effects then it cause issues to our system.
b) It causes threads leak issue, as threads are costly resources. Ya, I know thought of Threads was sold earlier, saying these as light weight. But note these are Light Weight Process, means compared to a Process, a Thread will be lightweight. But in reality every thread takes
resources & its not free, so thread is something should beb used wisely.
A Bit of History as I remember-
Till JDK1.5, threads were created whenever required & mostly without any control, causing applications getting stuck due to no thread available. And such issues were very difficult to
debug. Some people even tried to have some Threads pool & that made the code complex
one.
Then in JDK1.5, we got Executors library to have a threads pool from language itself along
with Future to have non-blocking flavour but Future didn't help much due to its blocking nature.
Executors causes Executors induced deadlock. Why? Because after a task split, that thread
sits idle in the pool which causes no threads in the pool, if such splits continues more than the
available threads in the pool.
Then JDK1.7, we got Fork-Join pool, which followed 'Work stealing' concept to avoid deadlock
due to idle threads in the pool earlier. But still concurrency was not an easy task to achieve.
Now JDK8 enters with CompletableFuture & Streams with rich set of libraries allowing to chain
the tasks being done in different threads. But still we are using Platform threads & still not easy to control those threads if any thread fails, still other threads will continue to run till the
application is up, as their scope is tied to the application.
Project Loom was introduced & it introduced the concept of Virtual Threads which became a stable feature in JDK21. This makes Java based Virtual Threads in JVM, which are mounted
over Platform threads to get the job done & if an I/O or any other blocking call occurs, then this virtual thread is unmounted from the Platform thread, so that other virtual thread can be
mounted to keep Platform thread busy.
But still that concern about leaky threads exist, even after using Virtual threads.
StructuredConcurrency came as part of JEP428 & one can read this JEP.
But still I don't understand this name StructuredConcurrency, to me it looks more like some
ManagedConcurrency.
Check below links to get an idea about & I will share somem code soon-
belief-driven-design.com/looking-at-java-21-structured-concurrency-39a81/
https://medium.com/wearewaes/structured-concurrency-with-java-21-in-4-steps-37e72997ed2a
https://medium.com/@phoenixrising_93140/what-is-structured-concurrency-java-21-6134374696be
https://docs.oracle.com/en/java/javase/21/core/structured-concurrency.html#GUID-B1AAAFB8-56E1-4289-8EAF-4BF581BF28FF
Java Structured Concurrency and StructuredTaskScope (howtodoinjava.com)
Before we talk about this term, I think will better to understand 'Concurrency' and
'Parallelism'.
Concurrency - As per my understanding, it is like one person doing more than 1 task.
What does it mean?
Does it mean that the same person is having multiple tasks at the same time?
Does it mean that the same person is doing multiple tasks at the same time?
It means, yes, the same person is having multiple tasks to do.
But it doesn't mean that the same person is taking actions on multiple tasks at the same time.
Obviously, no person can work on multiple tasks at the same moment, all requiring its same resource e.g. 'Brain'.
So a person does context switching or alternate between different tasks assigned, to show the progress in every task.
But that person will be working only on one task at a particular moment.
And a successful concurrency will be, if no task is corrupted due to other task with that person.
Same goes for Processor, a single processor does multiple tasks concurrently & does lot of context switching & it feels that all tasks are being done at the same time.
Will suggest to read more about Concurrency.
Parallelism - It is like multiple tasks being done by multiple people.
And, yes, here all people can continue to work on their respective tasks at the same time.
Same thing goes for Computers which have multiple cores allowing each core to work on
different task.
Will suggest to read more about this.
But what issue we are talking about here? In multithreading we start multiple threads to work
on multiple sub-tasks to get the main task done.
Our main task will be done successfully only when all its sub-tasks complete successfully.
So if any sub-task fails then we don't need other sub-tasks to continue but their threads are already out there which continue their processing & it becomes a concern-
a) If those sub-tasks cause side-effects then it cause issues to our system.
b) It causes threads leak issue, as threads are costly resources. Ya, I know thought of Threads was sold earlier, saying these as light weight. But note these are Light Weight Process, means compared to a Process, a Thread will be lightweight. But in reality every thread takes
resources & its not free, so thread is something should beb used wisely.
A Bit of History as I remember-
Till JDK1.5, threads were created whenever required & mostly without any control, causing applications getting stuck due to no thread available. And such issues were very difficult to
debug. Some people even tried to have some Threads pool & that made the code complex
one.
Then in JDK1.5, we got Executors library to have a threads pool from language itself along
with Future to have non-blocking flavour but Future didn't help much due to its blocking nature.
Executors causes Executors induced deadlock. Why? Because after a task split, that thread
sits idle in the pool which causes no threads in the pool, if such splits continues more than the
available threads in the pool.
Then JDK1.7, we got Fork-Join pool, which followed 'Work stealing' concept to avoid deadlock
due to idle threads in the pool earlier. But still concurrency was not an easy task to achieve.
Now JDK8 enters with CompletableFuture & Streams with rich set of libraries allowing to chain
the tasks being done in different threads. But still we are using Platform threads & still not easy to control those threads if any thread fails, still other threads will continue to run till the
application is up, as their scope is tied to the application.
Project Loom was introduced & it introduced the concept of Virtual Threads which became a stable feature in JDK21. This makes Java based Virtual Threads in JVM, which are mounted
over Platform threads to get the job done & if an I/O or any other blocking call occurs, then this virtual thread is unmounted from the Platform thread, so that other virtual thread can be
mounted to keep Platform thread busy.
But still that concern about leaky threads exist, even after using Virtual threads.
StructuredConcurrency came as part of JEP428 & one can read this JEP.
But still I don't understand this name StructuredConcurrency, to me it looks more like some
ManagedConcurrency.
Check below links to get an idea about & I will share somem code soon-
belief-driven-design.com/looking-at-java-21-structured-concurrency-39a81/
https://medium.com/wearewaes/structured-concurrency-with-java-21-in-4-steps-37e72997ed2a
https://medium.com/@phoenixrising_93140/what-is-structured-concurrency-java-21-6134374696be
https://docs.oracle.com/en/java/javase/21/core/structured-concurrency.html#GUID-B1AAAFB8-56E1-4289-8EAF-4BF581BF28FF
Java Structured Concurrency and StructuredTaskScope (howtodoinjava.com)
