Talk:Structured concurrency

"History" should not enumerate every implementation

> In 2021, Swift adopted structured concurrency. Later that year, a draft proposal was published to add structured concurrency to Java.

I think the point of the History section was to explain the origins of structured concurrency and cite contributors.

The citations for Swift and Java sound like implementations of what was already established. Perhaps there should be a separate section enumerating implementations. Lucenty (talk) 11:37, 3 September 2022 (UTC)

Structured concurrency has existed for at least 52 years

This article claims that structured concurrency was first proposed in 2016. It seems more accurate to say that structured concurrency is a very old idea that has had a recent resurgence in popularity.

Chapter 15 of the reference manual for PL/I (F), a programming language from 1972, presents a multitasking system where a task can spawn attached subtasks. And in particular:

> When a task is terminated, any of its subtasks that are still active are abnormally terminated.

Ada '83 has a similar feature. To quote the reference manual:

> If a task has dependent tasks, its termination takes place when the execution of the task is completed and all dependent tasks are terminated. A block statement or subprogram body whose execution is completed is not left until all of its dependent tasks are terminated.

This Wikipedia article doesn't mention any of this very similar prior work. This seems like a major oversight. 157.211.234.44 (talk) 06:15, 3 July 2024 (UTC)

Are there secondary sources which compare this prior work to its modern implementations? Or at least some source which calls the PL/I's version of it "structural concurrency"? Doing such a comparison ourselves would be original research, which is undesirable. —⁠andrybak (talk) 09:02, 3 July 2024 (UTC)

Unfortunately no, I don't know of any high-quality secondary sources that compare this recent rediscovery to these older languages.

However, I've located more resources on the topic of "structured parallelism". This seems to be a more established term than "structured concurrency". The latter term only gained traction after Smith's blog post from 2018.

From "Structured Parallel Programming" (2012):

> In this book, we propose the use of structured patterns of parallelism. These are akin to the patterns of structured control flow used in serial programming. Just as structured control flow replaced the use of goto in most programs, these patterns have the potential to replace low-level and architecture-specific parallel mechanisms such as threads and vector intrinsics.

This paper from 2010 claims the "structured parallelism" is an established term that incorporates classic languages that offer fork-join concurrency:

> Experience has shown that the proper coordination of parallel processes is an extremely demanding task for human designers and, therefore, very error-prone. Hence, it appears to be appropriate to sacrifice some flexibility in favour of predictability and simplicity. A very early proposal has been the "fork-and-join" mechanism [17] that also appears in the form of the "parallel clause" in ALGOL 68 [18] and later in OCCAM [19]. Based on this concept the error-prone constructs for independent activation and termination of individual processes (like in nearly all known real-time programming languages) can be replaced by a "parallel clause" or "process cluster". By now, this is also widely known under the name of "structured parallelism".

Indeed, this seems to be the case. For example, here's "P3L: a structured high-level parallel language" (1995), a paper published 15 years earlier:

> [P3L] constructs can be hierarchically composed to express, in a structured way, more complex forms of parallel computation. The P3L constructs are the only means that a programmer has to give parallel structure to an application. We have been supported in our choice by the evolution of sequential programming languages. In fact, a look at the history of imperative languages shows the progressive discarding of elementary constructs, e.g. gotos, in favour of a set of constructs with definite control flow behaviour, e.g. while, if, for, etc.

Of particular note here is that all of these authors are proposing and/or evaluating language constructs (including control flow constructs) that enable reasoning about the structure of a concurrent programs, and they make analogies to the "structured programming" movement of the 1970s, including the trouble with GOTO. This is the same analogy that Smith makes in his 2018 blog post, and Smith's solution is—like the cited authors—to employ control flow constructs to model concurrent tasks.

There is also this 2009 blog post from Herb Sutter, where he uses the phrase "unstructured concurrency" and also makes an analogy to GOTO.

Anyway, that's all of the time I'm willing to spend exploring this topic. Perhaps a future editor can integrate some of these resources into a new revision of the page. 157.211.234.44 (talk) 06:15, 8 July 2024 (UTC)