Synchronicity is the myth of
Today you are waiting for a long text without pictures (slightly reduced and compared with the original), where the thesis, taken out in the headline, is analyzed in detail. Microsoft Veteran Terry Crowley explains the essence of asynchronous programming and explains why this approach is much more realistic and more expedient than synchronous and sequential.
Those who want or are thinking about writing a book that deals with such topics - write in a personal.
often used to reduce the binding of .
Reduce costs and manage them. As mentioned above, any mechanism for hiding the asynchrony is associated with some allocation of resources and costs. For a particular application, such costs can be unacceptable, and the designer of this application must find a way to manage natural asynchrony.
An interesting example is the history of web servers. Early web servers (created on the basis of Unix) to control the incoming request usually branch out a separate process. Then this process could read this connection and write to it, it happened, in essence, synchronously. Such a design developed, and the costs were reduced when processes instead of processes began to be used, but the overall synchronous execution model was preserved. In modern design variants it is recognized that the main attention should be paid not to the model of computations, but, first of all, to the accompanying input /output associated with reading and writing when exchanging information with a database, file system or when transferring information over a network, . Usually, work queues are used for this, in which a certain number of threads are allowed - and in this case it is possible to more clearly build resource management.
The success of NodeJS in the backend development is explained not only by the support of this engine from the numerous jаvascript developers who grew up on the creation of client web interfaces. In NodeJS, as in browser-based scripting, much attention is paid to designing in an asynchronous key, which is well combined with typical server load options: server resource management depends primarily on I /O, and not on processing.
There is another interesting aspect: such trade-offs are more obvious and are more amenable to adjustment by the application developer, if you follow the asynchronous approach. In the example with delays in the memory hierarchy, the actual latency (measured in processor cycles in terms of a query in memory) has dramatically increased over several decades. The developers of the processors are struggling to add all the new levels of the cache and additional mechanisms that are increasingly pushing the memory model provided by the processor, so that this visibility of synchronous processing will continue to exist.
Context switching at the synchronous I /O boundaries is another example where actual trade-offs have changed dramatically over time. The increase in processor cycles occurs not in the example faster than the struggle with delays, and this means that now the application is missing much more computing capabilities while idle in the locked state, waiting for the completion of the IO. The same problem associated with the relative cost of compromises prompted OS designers to stick to memory management schemes that much more closely resemble earlier models with paging processes (where the entire image of the process is loaded into the memory, after which the process is already started), rather than paging pages. It is too difficult to hide the delays that can occur at the border of each page. The radically improved total throughput achieved by large consecutive IO queries (as compared to the use of random queries) also contributes to such changes.
The cancellation is a complex topic . Historically synchronous-oriented systems did not cope well with the cancellation processing, and some even did not support the cancellation at all. The cancellation in essence should be designed "out of band", for such an operation it was required to call a separate thread of execution. As an alternative, asynchronous models are suitable, where cancellation support is organized more naturally, in particular, this trivial approach is used: it simply ignores what response eventually returns (and returns at all). Cancellation is becoming more important when variability of delays increases, and in practice the frequency of errors increases - which gives a very good historical cut, demonstrating how our network environments evolved.
Throttling /Resource Management
Synchronous design by definition imposes some throttling, not allowing the application to issue additional requests until the current request is completed. In asynchronous design, throttling does not happen, so it is sometimes necessary to implement it explicitly. In this case post As an example, the situation is described with Word Web App, where the transition from synchronous design to asynchronous caused serious problems with resource management. If the application uses a synchronous interface, it may well not recognize that throttling is implicitly embeddedo in the code. When removing such an implicit throttling, you can (or you have to) more clearly organize the management of resources.
I had to face this at the very beginning of my career, when we ported the text editor from the synchronous Sun API to X Windows. When the Sun API was used, the rendering operation occurred synchronously, so that the client did not get control back until it was completed. In X Windows, the graphical request was dispatched asynchronously over a network connection, and then executed by a display server (which could be on the same or on another machine).
To ensure good interactive performance, our application must provide some rendering (i.e., ensure that the line in which the cursor is currently positioned is updated and rendered), and then check to see if there is any keyboard input that needs to be read. If such input exists, the program will throw the current screen (which somehow becomes irrelevant after processing the input that is currently in the queue) to read and process this input, and then redraw the screen taking into account the latest changes. Such a system was well configured to work with a synchronous graphical API. The asynchronous interface could accept drawing requests faster than they could execute, which is why the screen constantly hung from user input. This turned into a real nightmare when interactively stretching images, because the relative cost of issuing a new query was incomparably lower than the cost of its implementation. UI terribly hung up, performing a series of unnecessary redraws after each move of the mouse cursor.
This problem does not lose its relevance today, more than 30 years later (apparently, the Facebook app for iPhone in certain scenarios suffers exactly from the same problem). An alternative scheme is to write a special code to update the screen (which takes into account how often the screen can be updated), make it the master and explicitly direct the callback to the client to draw the area, rather than leave the client a leading role in this interaction. In this case, the client needs to observe a hard timekeeping so that this code works efficiently, and this is not always practical.
The complexity of
This whole topic eventually revolves around the relative complexity of creating applications built on asynchronous schemes. In one of my first lectures delivered at Microsoft's high-level internal technical seminar, I argued that asynchronous APIs are a key ingredient for creating applications that will not hang as often as the first programs for a PC. Butler Lampson, laureate of the Turing Award, one of the founders of the PC segment, sat in the gallery, and he exclaimed: "Yes, but they will not work either!" In the following years, I had a lot of discussions with Butler, but he remained deeply concerned about that , how to manage asynchrony on a large scale.
There are two key problems that arise with asynchronous design. The first is how to describe that the calculation must be restarted upon the arrival of the asynchronous response. In particular, there is such a problem: is it possible to find a layout method that supports the hiding of information necessary for building complex applications consisting of independent components. State machines that work in an explicit event-oriented manner are common. For practical solutions to such problems, language constructs are applicable, for example,
async /await or promises. More "rude" approaches, such as the use of callbacks, are very common in jаvascript code. In this case, there is such a problem: the long-term state of the program is buried under impenetrable callbacks, which often remain unmanageable and generally not manageable.
Async /await allows you to describe an asynchronous calculation, as if it were sequential, programmed in synchronous code. Under the hood, all this turns into chains of closures and continuation functions. This approach also provides a standard wrapping of asynchronous computations without requiring the use of spontaneous and inconsistent techniques that are observed in raw code based on callbacks.
But none of these approaches solves the second key problem. In essence, it boils down to how to isolate an intermediate state. With synchronous design, any intermediate state used in the calculations disappears, so after the synchronous calculation returns, it is no longer available. In asynchronous design, the same problem arises as in multithreaded, when different threads can operate on shared data (beware of dragons!). The intermediate state (potentially) can open, exponentially increasing the actual number of program states, judgments about which we need.
In fact, the leakage occurs in both directions. The internal state can be provided to the rest of the program, and a reference to the change of the external state can proceed from an asynchronous calculation. Such mechanisms as async /await, which intentionally build code so that it seems consistent and synchronous, do not clarify the risks that arise here, but only mask them.
As in the whole in the design, when you have to manage complexity, the isolation strategy comes to the fore, in particular - data isolation. One of the challenges when working with graphics applications is that the program may well need to inform the user about these intermediate states. The usual requirement is to demonstrate the progress of a particular calculation, or to interrupt, and then restart the calculation, which is affected by certain user actions (classical examples that fit into both these categories - page layout in Word or translation of results into Excel). In many cases that I have encountered over many years of practice, a lot of complexity is added because of attempts to determine how these intermediate program states should be presented to the user, rather than simply placing the cursor in the standby mode.
Specifically, for particularly long operations or for those where the risk of failure is high, the user is very anxious to understand what exactly is happening in the program.
Whichever strategy we choose, it is always useful to act in a disciplined and uniform manner - over time such a strategy necessarily pays off. Improvised approaches quickly slide down to incredible complexity.
The world is asynchronous. Synchronicity is a myth, and one that can cost you a pretty penny. Recognizing that asynchrony often allows a more plausible modeling of what is happening in the depth of our system, we can consciously manage all resources and costs. Complexity is associated with the increase in program states that are to be judged; To manage complexity, you need to isolate the state and limit the number of states visible for a particular piece of code.
It may be interesting
This is my first time i visit here. I found such a substantial number of interesting stuff in your blog especially its examination. Really its inconceivable article. Keep it up.Gulf Coast Western Reviews
I can see that you are an expert at your field! I am launching a website soon, and your information will be very useful for me.. Thanks for all your help and wishing you all the success in your business.GSM Solutions
Wow, What a Excellent post. I really found this to much informatics. It is what i was searching for.I would like to suggest you that please keep sharing such type of info.Thanksthc vape juice