Content deleted Content added
JnRouvignac (talk | contribs) Add categories |
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}},
==See also==
|