Structured concurrency: Difference between revisions

Content deleted Content added
Add categories
Lucenty (talk | contribs)
Clarify that structured concurrency isn't merely "splitting and joining", but making such structure evident in the code, and that this paradigm must permeate the program in order to be effective. (This is supported by cited material of all three authors of the concept.) Clarify that structured concurrency was arrived at independently by Sústrik, Smith, and Elizarov within a short span of a few years.
Line 1:
{{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]]. The core concept is that when control splits into concurrent tasks that they join up again, and that this control flow is readily evident by the structure of the source code. 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. To be effective, this model must be applied consistently throughout the program-- otherwise concurrent tasks may leak out, become orphaned, or fail to have runtime errors correctly propagated.
 
The naming is inspired by [[structured programming]], which created higher level control-flow statements out of the very basic [[goto]]. Similarly, structured concurrency creates higher level mechanisms for concurrency constructs out of the basic concurrent task creation constructs ([[Spawn (computing)|spawn]], [[Thread (computing)|thread]]s, [[Fiber (computer science)|fiber]]s).
 
The concept was formulated and named "structured concurrency" in 2016 by Martin Sústrik (creator of [[ZeroMQ]])<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>. Without knowledge of Sústrik's work{{Citation needed}}, andthe thenconcept furtherwas refinedindependently offered in April 2018 by Nathaniel J. Smith, who implemented it in the [https://trio.readthedocs.io/en/stable/ trioTrio]. library for Python<ref>{{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>, and in September 2018 by Roman Elizarov, 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>. (Smith happened to give the same name to concept, while Elizarov adopted the name after reading Smith's article, shortly before publishing his own work for Kotlin<ref>{{cite AV media |people=Elizarov, Roman |date=July 2019 |title=Structured concurrency |medium=Videotape |language=en |url=https://youtube.com/watch?v=Mj5P47F6nJg |access-date=21 September 2019 |publisher=Hydra Distributed computing conference |minutes=42 minutes in |quote="[...] we needed a name and we needed to finalize this whole concept [...] and [Nathaniel J. Smith] got a really good name for it, he called it structured concurrency."}}</ref>.)
 
==See also==