Asynchronous method invocation

In (multithreaded) object-oriented programming, asynchronous method invocation (AMI), also known as asynchronous method calls or asynchronous pattern is a client-side support that doesn't block the calling thread while waiting for a reply. Instead, the calling thread is notified when the reply arrives. Polling for a reply is an undesired option.

Background

AMI is a design pattern for asynchronous invocation of potentially long-running methods of an object.[1] It is equivalent to the IOU pattern described in 1996 by Allan Vermeulen.[2][3]

In most programming languages a called method is executed synchronously, i.e. in the thread of execution from which it is invoked. If the method needs a long time to completion, 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 future 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.

Implementations

Java class

FutureTask class[5] in Java use 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 software components.

.NET Framework

Example

The following example is loosely based on a standard AMI style used in the .NET Framework.[9] Given a method Accomplish, one adds two new methods BeginAccomplish and EndAccomplish:

 class Example 
 {
   Result       Accomplish(args …)
   IAsyncResult BeginAccomplish(args …)
   Result       EndAccomplish(IAsyncResult a)
   …
 }

Upon calling BeginAccomplish, the client immediately receives an object of type AsyncResult (which implements the IAsyncResult 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 EndAccomplish (passing the previously received object), which blocks until the method has completed and the result is available.[10] The AsyncResult object normally provides at least a method that allows the client to query whether the long-running method has already completed:

 interface IAsyncResult 
 {
    bool HasCompleted()
   …
 }

One can also pass a callback method to BeginAccomplish, to be invoked when the long-running method completes. It typically calls EndAccomplish 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 named AccomplishAsync instead of BeginAccomplish.[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 type AccomplishCompleted) in the same thread in which BeginAccomplish 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]

References

  1. ↑ "Asynchronous Method Invocation". Distributed Programming with Ice. ZeroC, Inc. Retrieved 22 November 2008.
  2. ↑ Vermeulen, Allan (June 1996). "An Asynchronous Design Pattern". Dr. Dobb's Journal. Retrieved 22 November 2008.
  3. ↑ Nash, Trey (2007). "Threading in C#". Accelerated C# 2008. Apress. ISBN 978-1-59059-873-3.
  4. ↑ Lavender, R. Greg; Douglas C. Schmidt. "Active Object" (PDF). Retrieved 22 November 2008.
  5. ↑ "Class FutureTask". Oracle. 2011. Retrieved 2015-06-29.
  6. ↑ "Asynchronous Programming Model". Microsoft. 2015. Retrieved 2015-06-29.
  7. ↑ "Event-based Asynchronous Pattern Overview". Microsoft. 2015. Retrieved 2015-06-29.
  8. ↑ "Task-based Asynchronous Pattern". Microsoft. 2015. Retrieved 2015-06-29.
  9. ↑ "Asynchronous Programming Design Patterns". .NET Framework Developer's Guide. Microsoft Developer Network. Archived from the original on 22 November 2008. Retrieved 22 November 2008.
  10. ↑ "Asynchronous Programming Overview". .NET Framework Developer's Guide. Microsoft Developer Network. Archived from the original on 7 December 2008. Retrieved 22 November 2008.
  11. ↑ "Using an AsyncCallback Delegate to End an Asynchronous Operation". .NET Framework Developer's Guide. Microsoft Developer Network. Archived from the original on 23 December 2008. Retrieved 22 November 2008.
  12. ↑ "Concurrency Issues". Distributed Programming with Ice. ZeroC, Inc. Retrieved 22 November 2008.
  13. ↑ Christian Nagel, Bill Evjen, Jay Glynn, Karli Watson, and Morgan Skinner (2008). "Event-based Asynchronous Pattern". Professional C# 2008. Wiley. pp. 570–571. ISBN 9780470191378.
  14. ↑ "Multithreaded Programming with the Event-based Asynchronous Pattern". .NET Framework Developer's Guide. Microsoft Developer Network. Archived from the original on 25 December 2008. Retrieved 22 November 2008.
  15. ↑ "Deciding When to Implement the Event-based Asynchronous Pattern". .NET Framework Developer's Guide. Microsoft Developer Network. Archived from the original on 22 November 2008. Retrieved 22 November 2008.

Further reading

This article is issued from Wikipedia - version of the Friday, January 08, 2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.