Inmultithreadedcomputer programming,asynchronous method invocation (AMI), also known asasynchronous method calls or theasynchronous pattern is adesign pattern in which the call site is notblocked while waiting for the called code to finish. Instead, the calling thread is notified when the reply arrives. Polling for a reply is an undesired option.
AMI is adesign pattern forasynchronous invocation of potentially long-runningmethods of anobject.[1]It is equivalent to the IOU ("I owe you") pattern described in 1996 by Allan Vermeulen.[2][3]
In most programming languages a called method is executed synchronously, i.e. in thethread of execution from which it is invoked. If the method takes a long time to complete, e.g. because it is loading data over the internet, the calling thread is blocked until the method has finished. When this is not desired, it is possible to start a "worker thread" and invoke the method from there. In most programming environments this requires many lines of code, especially if care is taken to avoid the overhead that may be caused by creating many threads. AMI solves this problem in that it augments a potentially long-running ("synchronous") object method with an "asynchronous" variant that returns immediately, along with additional methods that make it easy to receive notification of completion, or to wait for completion at a later time.
One common use of AMI is in theactive object design pattern. Alternatives are synchronous method invocation andfuture objects.[4]An example for an application that may make use of AMI is a web browser that needs to display a web page even before all images are loaded.
Sincemethod is a special case ofprocedure,asynchronous method invocation is a special case ofasynchronous procedure call.
FutureTask class[5] inJava useevents to solve the same problem. This pattern is a variant of AMI whose implementation carries more overhead, but it is useful for objects representingsoftware components.
The following example is loosely based on a standard AMI style used in the.NET Framework.[9]Given a methodAccomplish, one adds two new methodsBeginAccomplish andEndAccomplish:
classExample{ResultAccomplish(args…)IAsyncResultBeginAccomplish(args…)ResultEndAccomplish(IAsyncResulta)…}
Upon callingBeginAccomplish, the client immediately receives an object of typeAsyncResult (which implements theIAsyncResult interface), so it can continue the calling thread with unrelated work. In the simplest case, eventually there is no more such work, and the client callsEndAccomplish (passing the previously received object), which blocks until the method has completed and the result is available.[10] TheAsyncResult object normally provides at least a method that allows the client to query whether the long-running method has already completed:
interfaceIAsyncResult{boolHasCompleted()…}
One can also pass a callback method toBeginAccomplish, to be invoked when the long-running method completes. It typically callsEndAccomplish to obtain the return value of the long-running method. A problem with the callback mechanism is that the callback function is naturally executed in the worker thread (rather than in the original calling thread), which may cause race conditions.[11][12]
In the .NET Framework documentation, the term event-based asynchronous pattern refers to an alternative API style (available since .NET 2.0) using a method namedAccomplishAsync instead ofBeginAccomplish.[13][14]A superficial difference is that in this style the return value of the long-running method is passed directly to the callback method. Much more importantly, the API uses a special mechanism to run the callback method (which resides in an event object of typeAccomplishCompleted) in the same thread in whichBeginAccomplish was called. This eliminates the danger of race conditions, making the API easier to use and suitable for software components; on the other hand this implementation of the pattern comes with additional object creation and synchronization overhead.[15]
{{cite journal}}:Cite journal requires|journal= (help)