Structured concurrency: Difference between revisions

Revision as of 14:26, 19 March 2021

Latest revision as of 10:51, 14 June 2024

(14 intermediate revisions by 9 users not shown)

Line 1:

{{Short description|Programming paradigm for improving clarity and development time of a computer program}}

{{Programming paradigms}}

'''Structured concurrency''' is a [[programming paradigm]] aimed at improving the clarity, quality, and development time of a [[computer program]] by using a structured approach to [[concurrent computing|concurrent programming]].

'''Structured concurrency''' is a [[programming paradigm]] aimed at improving the clarity, quality, and development time of a [[computer program]] by using a structured approach to [[concurrent computing|concurrent programming]]. The core concept is the encapsulation of concurrent threads of execution (here encompassing kernel and userland threads and processes) by way of control flow constructs that have clear entry and exit points and that ensure all spawned threads have completed before exit. The concept is analogous to [[structured programming]], which introduced control flow constructs that encapsulated sequential statements and subroutines. Such encapsulation allows errors in concurrent threads to be propagated to the control structure's parent scope and managed by the native error handling mechanisms of each particular computer language. It allows control flow to remain readily evident by the structure of the source code despite the presence of concurrency. To be effective, this model must be applied consistently throughout all levels of the program – otherwise concurrent threads may leak out, become orphaned, or fail to have runtime errors correctly propagated.

'''Structured concurrency''' is a [[programming paradigm]] aimed at improving the clarity, quality, and development time of a [[computer program]] by using a structured approach to [[concurrent computing|concurrent programming]]. The core concept is the encapsulation of concurrent threads of execution (here encompassing kernel and userland threads and processes) by way of control flow constructs that have clear entry and exit points and that ensure all spawned threads have completed before exit. The concept is analogous to [[structured programming]], which introduced control flow constructs that encapsulated sequential statements and subroutines. Such encapsulation allows errors in concurrent threads to be propagated to the control structure's parent scope and managed by the native error handling mechanisms of each particular computer language. It allows control flow to remain readily evident by the structure of the source code despite the presence of concurrency. To be effective, this model must be applied consistently throughout all levels of the program – otherwise concurrent threads may leak out, become orphaned, or fail to have runtime errors correctly propagated.

== History ==

The [[fork–join model]] from the 1960s, embodied by multiprocessing tools like [[OpenMP]], is an early example of a system ensuring all threads have completed before exit. However, Smith argues that this model is not true structured concurrency as the programming language is unaware of the joining behavior.<ref name=smith/>

Structured concurrency is analogous to [[structured programming]], which uses control flow constructs that encapsulate sequential statements and subroutines.

The concept was formulated in 2016 by Martin Sústrik (creator of [[ZeroMQ]]) with his C library libdill,<ref>{{cite web |last1=Sústrik |first1=Martin |title=Structured Concurrency |url=http://250bpm.com/blog:71 |date=7 February 2016 |accessdate=1 August 2019}}</ref> and then further refined in 2018 by Nathaniel J. Smith, who implemented it in a Python library called Trio.<ref name=smith>{{cite web |last1=Smith |first1=Nathaniel J. |title=Notes on structured concurrency, or: Go statement considered harmful |url=https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/ |date=25 April 2018 |accessdate=1 August 2019}}</ref> Meanwhile, Roman Elizarov independently came upon the same ideas while developing an experimental coroutine library for the Kotlin language.<ref>{{cite web |last1=Elizarov |first1=Roman |title=Structured concurrency |url=https://medium.com/@elizarov/structured-concurrency-722d765aa952 |date=12 September 2018 |accessdate=21 September 2019}}</ref><ref>{{cite AV media |people=Elizarov, Roman |date=July 2019 |title=Structured concurrency |medium=Videotape |language=en |url=https://youtube.com/watch?v=Mj5P47F6nJg&t=2538 |access-date=21 September 2019 |publisher=Hydra Distributed computing conference |minutes=42 |quote="We needed a name and we needed to finalize this whole concept [...] and we stumble onto this blog post [...] by Nathaniel J. Smith."}}</ref>

== History ==

In 2019, the loom project from [[OpenJDK]] is adopting structured concurrency to bring it to the [[Java platform]] in a future release as part of a larger work on [[lightweight thread]]s and [[coroutine]]s.<ref>{{cite web |last1=Bateman |first1=Alan |website=openjdk.java.net |publisher=[[OpenJDK]] |access-date=November 23, 2019 |title=Structured concurrency |url=https://wiki.openjdk.java.net/display/loom/Structured+Concurrency}}</ref>

The [[fork–join model]] from the 1960s, embodied by multiprocessing tools like [[OpenMP]], is an early example of a system ensuring all threads have completed before exit. However, Smith argues that this model is not true structured concurrency as the programming language is unaware of the joining behavior, and is thus unable to enforce safety.<ref>{{cite nameweb |last1=smithSmith |first1=Nathaniel J. |title=Notes on structured concurrency, or: Go statement considered harmful |url=https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/ |date=25 April 2018 |access-date=1 August 2019}}</ref>

The concept was formulated in 2016 by Martin Sústrik (creatora developer of [[ZeroMQ]]) with his C library libdill, with [[Go_(programming_language)#Concurrency:_goroutines_and_channels|goroutines]] as a starting point.<ref>{{cite web |last1=Sústrik |first1=Martin |title=Structured Concurrency |url=http://250bpm.com/blog:71 |date=7 February 2016 |accessdateaccess-date=1 August 2019}}</ref> andIt thenwas further refined in 20182017 by Nathaniel J. Smith, who implementedintroduced ita "nursery pattern" in ahis [[Python library(programming language)|Python]] implementation called Trio.<ref name=smith>{{cite web |last1=Smith |first1=Nathaniel J. |title=NotesAnnouncing on structured concurrency, or: Go statement considered harmfulTrio |url=https://vorpus.org/blog/notesannouncing-on-structured-concurrency-or-go-statement-considered-harmfultrio/ |date=2510 AprilMarch 20182017 |accessdateaccess-date=123 AugustSeptember 20192022}}</ref> Meanwhile, Roman Elizarov independently came upon the same ideas while developing an experimental [[coroutine]] library for the [[Kotlin (programming language.)|Kotlin language]],<ref>{{cite web |last1=Elizarov |first1=Roman |title=Structured concurrency |url=https://medium.com/@elizarov/structured-concurrency-722d765aa952 |date=12 September 2018 |accessdateaccess-date=21 September 2019}}</ref><ref>{{cite AV media |people=Elizarov, Roman |date=11 July 2019 |title=Structured concurrency |medium=VideotapeVideo |language=en |url=https://youtube.com/watch?v=Mj5P47F6nJg&t=2538 |access-date=21 September 2019 |publisher=Hydra Distributed computing conference |minutes=42 |quote="We needed a name and we needed to finalize this whole concept [...] and we stumble onto this blog post [...] by Nathaniel J. Smith."}}</ref> which later became a standard library.<ref>{{cite web | url=https://kotlinlang.org/docs/coroutines-basics.html#structured-concurrency | title=Coroutines basics: Structured concurrency | website=Kotlin | publisher=JetBrains | access-date=3 March 2022}}</ref>

In 2020, [[Swift (programming language)|Swift]] is mentioning adoption of structured concurrency in their concurrency roadmap.<ref>{{cite web |last1=Cohen |first1=Ben |website=swift.org |publisher=[[Swift (programming language)|Swift]] |access-date=October 31, 2020|title=Swift Concurrency Roadmap |url=https://forums.swift.org/t/swift-concurrency-roadmap/41611}}</ref>

In 2021, [[Swift (programming language)|Swift]] adopted structured concurrency.<ref>{{cite web |first1=John |last1=McCall |first2=Joe |last2=Groff |first3=Doug |last3=Gregor |first4=Konrad |last4=Malawski |access-date=3 March 2022 |title=Swift Structured Concurrency Proposal |website=Apple's Swift Evolution repo |publisher=GitHub |url=https://github.com/apple/swift-evolution/blob/main/proposals/0304-structured-concurrency.md}}</ref> Later that year, a draft proposal was published to add structured concurrency to [[Java (programming language)|Java]].<ref>{{cite web |last1=Pressler |first1=Ron |website=[[OpenJDK]] |publisher=Oracle |access-date=3 March 2022 |title=JEP draft: Structured Concurrency (Incubator) |url=https://openjdk.java.net/jeps/8277129}}</ref>

== Variations ==

Line 18 ⟶ 20:

== References ==

=== Citations ===

{{Reflist}}

=== External links===

* [https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/ Notes on structured concurrency, or: Go statement considered harmful] by Nathaniel J. Smith

* [https://wiki.openjdk.java.net/display/loom/Structured+Concurrency Structured Concurrency], Alan Bateman, [[OpenJDK]] wiki

* [https://trio.discourse.group/c/structured-concurrency Structured concurrency forum], cross-computer-language discussion of structured concurrency with participation by Sústrik, Smith, and Elizarov

* [https://archive.fosdem.org/2019/schedule/event/structured_concurrency/ FOSDEM 2019: Structured Concurrency], lightning talk by Martin Sustrik with links to some implementations

{{Programming paradigms navbox}}

[[Category:Programming paradigms]]