Asynchronous method invocation: Difference between revisions

Revision as of 16:30, 2 December 2015

Latest revision as of 23:29, 30 May 2025

(27 intermediate revisions by 18 users not shown)

Line 1:

{{Short description|Software design pattern}}

In ([[Thread (computer science)|multithreaded]]) [[object-orientedcomputer programming]], '''asynchronous method invocation''' ('''AMI'''), also known as '''asynchronous method calls''' or the '''asynchronous pattern''' is a client-side[[software supportdesign thatpattern|design doesn'tpattern]] blockin which the callingcall threadsite is not [[Blocking (computing)|blocked]] while waiting for athe called code to replyfinish. Instead, the calling thread is notified when the reply arrives. Polling for a reply is an undesired option.

== Background ==

'''AMI''' is a [[software design pattern|design pattern]] for [[asynchronousasynchrony I/O(computer programming)|asynchronous]] invocation of potentially long-running [[method (computer science)|methods]] of an [[object (computer science)|object]].<ref name="Async.34.2#71139">{{cite web |url=http://www.zeroc.com/doc/Ice-3.2.1/manual/Async.34.2.html#71139 |title=Asynchronous Method Invocation |accessdateaccess-date= 22 November 2008 |workwebsite=Distributed Programming with Ice |publisher=ZeroC, Inc. |url-status=dead |archive-url=https://web.archive.org/web/20080105093534/http://www.zeroc.com/doc/Ice-3.2.1/manual/Async.34.2.html |archive-date=5 January 2008 }}</ref>

It is equivalent to the [[IOU]] ("I owe you") pattern described in 1996 by Allan Vermeulen.<ref>{{cite journal |last=Vermeulen |first=Allan |date=June 1996 |title=An Asynchronous Design Pattern |journal=[[Dr. Dobb's Journal]] |url=http://www.ddj.com/184409898 |accessdateaccess-date=22 November 2008 }}</ref><ref>{{cite book |last=Nash |first=Trey |title=Accelerated C# 2008 | year=2007 |publisher=Apress |isbn=978-1-59059-873-3 |chapter=Threading in C# }}</ref>

In most programming languages a called method is executed synchronously, i.e. in the [[thread (computer science)|thread of execution]] from which it is invoked. If the method needstakes a long time to completioncomplete, 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 the [[active object]] design pattern. Alternatives are synchronous method invocation and [[futures and promises|future objects]].<ref name="active object">{{cite journal | last=Lavender | first=R. Greg | author2=[[Douglas C. Schmidt]] | title=Active Object | url=http://www.cs.wustl.edu/~schmidt/PDF/Act-Obj.pdf | formataccess-date=22 November 2008 | archive-url=https://web.archive.org/web/20120722180050/http://www.cs.wustl.edu/%7Eschmidt/PDF/Act-Obj.pdf | accessdatearchive-date=2012-07-22 November| 2008url-status=dead | author2-link=Douglas C. Schmidt }}</ref>

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.

Since [[method (computer science)|method]] is a special case of [[Procedure_(computer_science)|procedure]], '''asynchronous method invocation''' is a special case of [[asynchronous procedure call]].

== Implementations ==

=== Java class ===

FutureTask class<ref>{{cite web|title = Class FutureTask| |url = https://docs.oracle.com/javase/6/docs/api/java/util/concurrent/FutureTask.html(v |archive-url=vshttp://webarchive.110)loc.aspxgov/all/20130625215130/http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/FutureTask.html |url-status=dead |archive-date=2013-06-25 |publisher=Oracle |date=2011 |access-date=2015-06-29 }}</ref> in [[Java (programming language)|Java]] use [[event (synchronization primitive)|events]] to solve the same problem. This pattern is a variant of AMI whose implementation carries more overhead, but it is useful for objects representing [[Component-based software engineering|software components]].

=== .NET Framework ===

Line 22 ⟶ 25:

====Example====

The following example is loosely based on a standard AMI style used in the [[.NET Framework]].<ref name="ms228969">{{cite web |url=http://msdn.microsoft.com/en-us/library/ms228969.aspx |title=Asynchronous Programming Design Patterns |accessdateaccess-date=22 November 2008 |workwebsite=.NET Framework Developer's Guide |publisher=Microsoft Developer Network| archiveurlarchive-url= httphttps://web.archive.org/web/20081122091746/http://msdn.microsoft.com/en-us/library/ms228969.aspx| archivedatearchive-date= 22 November 2008 <!--DASHBot-->| deadurlurl-status= nolive}}</ref>

Given a method <code>Accomplish</code>, one adds two new methods <code>BeginAccomplish</code> and <code>EndAccomplish</code>:

<sourcesyntaxhighlight lang="csharp">

Classclass Example

{

Result Accomplish(args …)

IAsyncResult BeginAccomplish(args …)

Result EndAccomplish(IAsyncResult a)

…

}</syntaxhighlight>

}</source>

Upon calling <code>BeginAccomplish</code>, the client immediately receives an object of type <code>AsyncResult</code> (which implements the <code>IAsyncResult</code> 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 calls <code>EndAccomplish</code> (passing the previously received object), which blocks until the method has completed and the result is available.<ref name="ms228963">{{cite web |url=http://msdn.microsoft.com/en-us/library/ms228963.aspx |title=Asynchronous Programming Overview |accessdateaccess-date= 22 November 2008 |workwebsite=.NET Framework Developer's Guide |publisher=Microsoft Developer Network| archiveurlarchive-url= httphttps://web.archive.org/web/20081207092841/http://msdn.microsoft.com/en-us/library/ms228963.aspx| archivedatearchive-date= 7 December 2008 <!--DASHBot-->| deadurlurl-status= nolive}}</ref> The <code>AsyncResult</code> object normally provides at least a method that allows the client to query whether the long-running method has already completed:

<sourcesyntaxhighlight lang="csharp">

Interfaceinterface IAsyncResult

{

bool HasCompleted()

…

}</syntaxhighlight>

}</source>

One can also pass a callback method to <code>BeginAccomplish</code>, to be invoked when the long-running method completes. It typically calls <code>EndAccomplish</code> 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.<ref name="ms228972">{{cite web |url=http://msdn.microsoft.com/en-us/library/ms228972.aspx |title=Using an AsyncCallback Delegate to End an Asynchronous Operation |accessdateaccess-date= 22 November 2008 |workwebsite=.NET Framework Developer's Guide |publisher=Microsoft Developer Network| archiveurlarchive-url= httphttps://web.archive.org/web/20081223205326/http://msdn.microsoft.com/en-us/library/ms228972.aspx| archivedatearchive-date= 23 December 2008 <!--DASHBot-->| deadurlurl-status= nolive}}</ref><ref name="Async.34.3#76161">{{cite web |url=http://www.zeroc.com/doc/Ice-3.2.1/manual/Async.34.3.html#76161 |title=Concurrency Issues |accessdateaccess-date= 22 November 2008 |workwebsite=Distributed Programming with Ice |publisher=ZeroC, Inc. |url-status=dead |archive-url=https://web.archive.org/web/20080328070322/http://www.zeroc.com/doc/Ice-3.2.1/manual/Async.34.3.html |archive-date=28 March 2008 }}</ref>

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 named <code>AccomplishAsync</code> instead of <code>BeginAccomplish</code>.<ref name=nageletal>{{cite book|title=Professional C# 2008|authorurl=https://archive.org/details/professionalcsha2008nage|url-access=limited|author1=Christian Nagel, |author2=Bill Evjen, |author3=Jay Glynn, |author4=Karli Watson, and |author5=Morgan Skinner |name-list-style=amp |pages=[https://archive.org/details/professionalcsha2008nage/page/n630 570]&ndash;571|publisher=Wiley|year=2008|isbn13isbn=9780470191378|chapter=Event-based Asynchronous Pattern}}</ref><ref name="hkasytyf">{{cite web |url=http://msdn.microsoft.com/en-us/library/hkasytyf.aspx |title=Multithreaded Programming with the Event-based Asynchronous Pattern |accessdateaccess-date= 22 November 2008 |workwebsite=.NET Framework Developer's Guide |publisher=Microsoft Developer Network| archiveurlarchive-url= httphttps://web.archive.org/web/20081225175311/http://msdn.microsoft.com/en-us/library/hkasytyf.aspx| archivedatearchive-date= 25 December 2008 <!--DASHBot-->| deadurlurl-status= nolive}}</ref>

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 type <code>AccomplishCompleted</code>) in the same thread in which <code>BeginAccomplish</code> 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.<ref name="ms228966">{{cite web |url=http://msdn.microsoft.com/en-us/library/ms228966.aspx |title=Deciding When to Implement the Event-based Asynchronous Pattern |accessdateaccess-date= 22 November 2008 |workwebsite=.NET Framework Developer's Guide |publisher=Microsoft Developer Network| archiveurlarchive-url= httphttps://web.archive.org/web/20081122092048/http://msdn.microsoft.com/en-us/library/ms228966.aspx| archivedatearchive-date= 22 November 2008 <!--DASHBot-->| deadurlurl-status= nolive}}</ref>

==References==

Line 52 ⟶ 55:

== Further reading ==

* {{cite book|title=Programming WPF|authorurl=https://archive.org/details/programmingwpfbu00sell|url-access=limited|author1=Chris Sells and |author2=Ian Griffiths |name-list-style=amp |chapter=Appendix C.3: The Event-Based Asynchronous Pattern|pages=[https://archive.org/details/programmingwpfbu00sell/page/n773 747]&ndash;749|publisher=O'Reilly|year=2007|isbn13isbn=9780596510374}}

* [http://articles.techrepublic.com.com/5100-10878_11-1044325.html Using asynchronous method calls in C#]