Structured concurrency

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 programming.

Programming paradigms

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. 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 analogous to structured programming, which introduced control flow constructs that encapsulated sequential statements and subroutines.

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, and is thus unable to enforce safety.[1]

The concept was formulated in 2016 by Martin Sústrik (creator of ZeroMQ) with his C library libdill, with goroutines as a starting point.[2] It was further refined in 2017 by Nathaniel J. Smith, who introduced a "nursery pattern" in his Python implementation called Trio.[3] Meanwhile, Roman Elizarov independently came upon the same ideas while developing an experimental coroutine library for the Kotlin language,[4][5] which later became a standard library.[6]

In 2021, Swift adopted structured concurrency.[7] Later that year, a draft proposal was published to add structured concurrency to Java.[8]

Variations

A major point of variation is how an error in one member of a concurrent thread tree is handled. Simple implementations will merely wait until the children and siblings of the failing thread 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 threads in an expedient manner.

See also

References
  1. Smith, Nathaniel J. (25 April 2018). "Notes on structured concurrency, or: Go statement considered harmful". Retrieved 1 August 2019.
  2. Sústrik, Martin (7 February 2016). "Structured Concurrency". Retrieved 1 August 2019.
  3. Smith, Nathaniel J. (10 March 2017). "Announcing Trio". Retrieved 23 September 2022.
  4. Elizarov, Roman (12 September 2018). "Structured concurrency". Retrieved 21 September 2019.
  5. Elizarov, Roman (11 July 2019). Structured concurrency (Video). Hydra Distributed computing conference. 42 minutes in. Retrieved 21 September 2019. We needed a name and we needed to finalize this whole concept [...] and we stumble onto this blog post [...] by Nathaniel J. Smith.
  6. "Coroutines basics: Structured concurrency". Kotlin. JetBrains. Retrieved 3 March 2022.
  7. McCall, John; Groff, Joe; Gregor, Doug; Malawski, Konrad. "Swift Structured Concurrency Proposal". Apple's Swift Evolution repo. GitHub. Retrieved 3 March 2022.
  8. Pressler, Ron. "JEP draft: Structured Concurrency (Incubator)". OpenJDK. Oracle. Retrieved 3 March 2022.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.