Futures (informatique)
En programmation, les notions de futurs (« futures »), promesses (« promises ») ou délais (« delay ») font référence à des techniques de synchronisation pour certains langages concurrents. Il s'agit d'abstractions qui servent de proxy pour un résultat non-connu au moment où il est référencé pour la première fois, car son calcul ou son obtention se feront « plus tard » à l'exécution.
Le terme générique de promise (« promesse ») a été proposé par Daniel P. Friedman et David Wise en 1976[1] ; Peter Hibbard le dénommait eventual[2] à la même époque. Le concept similaire de future a été introduit en 1977 dans une publication de Henry Baker (en) et Carl Hewitt[3].
Les termes future, promise et delay sont la plupart du temps interchangeables, bien que certains programmeurs soulignent des différences entre future et promise. L'action consistant à attribuer sa valeur à une promise est la plupart du temps notée resolving, fulfilling ou binding.
Applications
[modifier | modifier le code]Les futurs et les promesses trouvent leur origine dans la programmation fonctionnelle et les paradigmes connexes (comme la programmation logique) pour découpler une valeur (un futur) de la façon dont elle a été calculée (une promesse), ce qui rend le calcul plus souple, notamment en le parallélisant. Plus tard, il a été utilisé dans le calcul distribué, en réduisant la latence des communications aller-retour et a ainsi gagné encore plus dans son utilisation en permettant d'écrire des programmes asynchrones dans un style direct (Direct style), plutôt que dans un style de continuation-passage (Continuation-passing style).
Implicite vs explicite
[modifier | modifier le code]L'utilisation de futurs peut être implicite : à chaque utilisation un futur obtient automatiquement sa valeur, comme si c'était un nombre ordinal ; ou explicite : l'utilisateur doit appeler une fonction pour obtenir sa valeur, comme la méthode get de java.util.concurrent.Future en Java. Obtenir une valeur d'un futur peut être appelé "stinging" ou "forcing". Les futurs explicites peuvent être implémentés comme une bibliothèque, tandis que les futurs implicites nécessitent un support du langage.
La publication originale de Baker et Hewitt décrit les futurs implicites, qui sont naturellement supportés par le Modèle d'acteur de la pure programmation orientée objet dans des langages de programmation comme Smalltalk. La publication de Friedman et Wise décrit uniquement les futurs explicites, pour répondre aux difficultés d'implémentation efficiente des futurs implicites dans certains langages. La difficulté est que les langages ne sont pas forcément capable de gérer les futurs pour des types de données primitives comme les entiers. Par exemple, une instruction add ne sait pas comment gérer 3 + future factorial(100000). En pur objet ou un langage d'acteur ce problème peut être résolu en envoyant au future factorial(100000) un message +[3] qui demande à ce futur d'ajouter 3 à lui-même et de retourner le résultat. Notez que le passage de message fonctionnera même si aucun stinging/forcing n'est utilisé quand factorial(100000) fini de s'exécuter.
Voir aussi
[modifier | modifier le code]- Pyramide condamnée, un antipattern de développement qui peut être résolu par l'utilisation de futures
Références
[modifier | modifier le code]- Daniel Friedman et David Wise « The Impact of Applicative Programming on Multiprocessing »
— « (ibid.) », dans International Conference on Parallel Processing, , p. 263-272. - Peter Hibbard « Parallel Processing Facilities » ()
— « (ibid.) », dans Stephen A. Schuman (éd.), New Directions in Algorithmic Languages, IRIA, - Henry Baker et Carl Hewitt « The Incremental Garbage Collection of Processes » ()
— « (ibid.) », dans Proceedings of the Symposium on Artificial Intelligence Programming Languages, coll. « SIGPLAN Notices » (no 12),
