Structured concurrency: Difference between revisions

Revision as of 01:15, 24 October 2019

Revision as of 02:01, 24 October 2019

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 thatthe whenencapsulation of concurrent threads of execution (here encompassing kernel and userland threads and processes) by way of control splitsflow intoconstructs concurrentthat taskshave clear entry and exit points and that theyensure joinall upspawned againthreads have completed before exit. The concept is analogous to [[structured programming]], which introduced control flow constructs that anyencapsulated tasksequential errorstatements isand subroutines. Such encapsulation allows errors in concurrent threads to be propagated to the spawningcontrol structure's parent scope (onceand managed by the task'snative childrenerror andhandling siblingmechanisms tasksof haveeach completed),particular andcomputer thatlanguage. this It allows control flow isto 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 tasksthreads 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 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>, and then further refined in 2018 by Nathaniel J. Smith, who implemented it in [https://trio.readthedocs.io/en/stable/ Trio].<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> 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>

==Variations==

A major point of variation is how an error in one member of a concurrent taskthread tree is handled. Simple implementations will merely wait until the children and siblings of the failing taskthread run to completion before propagating the error to the parent scope. However, that could take an indefinite amount of time. The alternative is to employ a general cancellation mechanism (typically a cooperative scheme allowing program invariants to be honored) to terminate the children and sibling tasksthreads in an orderly manner.

==See also==