Appel de méthode asynchrone

En programmation informatique multithread , l'invocation de méthode asynchrone ( AMI ), également connue sous le nom d'appels de méthode asynchrones ou de modèle asynchrone, est un modèle de conception dans lequel le site d'appel n'est pas bloqué en attendant la fin du code appelé. Au lieu de cela, le thread appelant est averti lorsque la réponse arrive. L'interrogation d'une réponse est une option indésirable.

AMI est un modèle de conception pour l'invocation asynchrone de méthodes potentiellement longues d'un objet . Il est équivalent au modèle IOU (« Je te dois ») décrit en 1996 par Allan Vermeulen.

Dans la plupart des langages de programmation, une méthode appelée est exécutée de manière synchrone, c'est-à-dire dans le thread d'exécution à partir duquel elle est invoquée. Si la méthode prend beaucoup de temps à s'exécuter, par exemple parce qu'elle charge des données sur Internet, le thread appelant est bloqué jusqu'à ce que la méthode soit terminée. Lorsque cela n'est pas souhaité, il est possible de démarrer un « thread de travail » et d'appeler la méthode à partir de là. Dans la plupart des environnements de programmation, cela nécessite de nombreuses lignes de code, en particulier si l'on prend soin d'éviter la surcharge qui peut être causée par la création de nombreux threads. AMI résout ce problème en augmentant une méthode d'objet potentiellement longue (« synchrone ») avec une variante « asynchrone » qui retourne immédiatement, ainsi que des méthodes supplémentaires qui facilitent la réception d'une notification d'achèvement ou l'attente de l'achèvement à un moment ultérieur.

L'AMI est couramment utilisé dans le modèle de conception d'objet actif . Les alternatives sont l'invocation de méthodes synchrones et les objets futurs . Un exemple d'application qui peut utiliser l'AMI est un navigateur Web qui doit afficher une page Web avant même que toutes les images ne soient chargées.

Étant donné qu'une méthode est un cas particulier de procédure , l'invocation d'une méthode asynchrone est un cas particulier d' appel de procédure asynchrone .

La classe FutureTask en Java utilise des événements pour résoudre le même problème. Ce modèle est une variante de l'AMI dont l'implémentation entraîne plus de frais généraux, mais il est utile pour les objets représentant des composants logiciels .

• Modèle de modèle de programmation asynchrone (APM) (utilisé avant .NET Framework 2.0)
• Modèle asynchrone basé sur les événements (EAP) (utilisé dans .NET Framework 2.0)
• Modèle asynchrone basé sur les tâches (TAP) (utilisé dans .NET Framework 4.0)

L'exemple suivant est vaguement basé sur un style AMI standard utilisé dans le .NET Framework . Étant donnée une méthode Accomplish, on ajoute deux nouvelles méthodes BeginAccomplishet EndAccomplish:

classe Exemple { Résultat Accomplish ( args … ) IAsyncResult BeginAccomplish ( args … ) Résultat EndAccomplish ( IAsyncResult a ) … }

Lors de l'appel à BeginAccomplish, le client reçoit immédiatement un objet de type AsyncResult(qui implémente l' IAsyncResultinterface), ce qui lui permet de continuer le thread appelant avec un travail sans rapport. Dans le cas le plus simple, il n'y a finalement plus de travail de ce type et le client appelle EndAccomplish(en passant l'objet reçu précédemment), qui se bloque jusqu'à ce que la méthode soit terminée et que le résultat soit disponible. L' AsyncResultobjet fournit normalement au moins une méthode qui permet au client de demander si la méthode de longue durée est déjà terminée :

interface IAsyncResult { bool HasCompleted () … }

On peut également passer une méthode de rappel à BeginAccomplish, qui sera invoquée lorsque la méthode de longue durée se termine. Elle appelle généralement EndAccomplishpour obtenir la valeur de retour de la méthode de longue durée. Un problème avec le mécanisme de rappel est que la fonction de rappel est naturellement exécutée dans le thread de travail (plutôt que dans le thread d'appel d'origine), ce qui peut provoquer des conditions de concurrence.

Dans la documentation de .NET Framework, le terme modèle asynchrone basé sur les événements fait référence à un style d'API alternatif (disponible depuis .NET 2.0) utilisant une méthode nommée AccomplishAsyncà la place de BeginAccomplish. Une différence superficielle est que dans ce style, la valeur de retour de la méthode à exécution longue est transmise directement à la méthode de rappel. Plus important encore, l'API utilise un mécanisme spécial pour exécuter la méthode de rappel (qui réside dans un objet événement de type AccomplishCompleted) dans le même thread dans lequel BeginAccomplishelle a été appelée. Cela élimine le risque de conditions de concurrence, ce qui rend l'API plus facile à utiliser et adaptée aux composants logiciels ; d'autre part, cette implémentation du modèle s'accompagne d'une surcharge supplémentaire de création et de synchronisation d'objets.

• Chris Sells et Ian Griffiths (2007). « Annexe C.3 : Le modèle asynchrone basé sur les événements ». Programmation WPF . O'Reilly. pp. 747–749. ISBN 9780596510374.
• Utilisation des appels de méthodes asynchrones en C#