Futuros y promesas

En informática , los futuros , las promesas , los retrasos y los diferidos son construcciones que se utilizan para sincronizar la ejecución de programas en algunos lenguajes de programación concurrentes . Cada uno es un objeto que actúa como un sustituto de un resultado inicialmente desconocido, generalmente porque el cálculo de su valor aún no ha finalizado.

El término promesa fue propuesto en 1976 por Daniel P. Friedman y David Wise, ^{[ 1 ]} y Peter Hibbard lo llamó eventual . ^{[ 2 ]} Un concepto algo similar, futuro, fue introducido en 1977 en un artículo de Henry Baker y Carl Hewitt . ^{[ 3 ]}

Los términos futuro , promesa , retraso y diferido se suelen usar indistintamente, aunque existen algunas diferencias en su uso . En concreto, cuando se distinguen, un futuro es una representación de una variable de solo lectura , mientras que una promesa es un contenedor de asignación única y modificable que establece el valor del futuro. Cabe destacar que un futuro puede definirse sin especificar qué promesa concreta establecerá su valor, y diferentes promesas pueden establecer el valor de un futuro dado, aunque esto solo puede hacerse una vez para un futuro determinado. En otros casos, un futuro y una promesa se crean juntos y se asocian entre sí: el futuro es el valor, la promesa es la función que establece el valor; esencialmente, el valor de retorno (futuro) de una función asíncrona (promesa). Establecer el valor de un futuro también se denomina resolverlo , cumplirlo o vincularlo .

Las promesas y los futuros se originaron en la programación funcional y paradigmas relacionados (como la programación lógica ) para desacoplar un valor (un futuro) de cómo se calculaba (una promesa), lo que permitía realizar el cálculo de forma más flexible, sobre todo mediante la paralelización. Posteriormente, se utilizaron en la computación distribuida para reducir la latencia de las comunicaciones. Más tarde, su uso se amplió al permitir escribir programas asíncronos de forma directa , en lugar de hacerlo mediante el paso de continuaciones .

El uso de futuros puede ser implícito (cualquier uso del futuro obtiene automáticamente su valor, como si fuera una referencia ordinaria ) o explícito (el usuario debe llamar a una función para obtener el valor, como el getmétodo `get` java.util.concurrent.Futureen Java ). Obtener el valor de un futuro explícito se denomina "stinging" o "forcing" . Los futuros explícitos pueden implementarse como una biblioteca, mientras que los futuros implícitos suelen implementarse como parte del lenguaje.

El artículo original de Baker y Hewitt describía futuros implícitos, que son soportados naturalmente en el modelo de actor de computación y en lenguajes de programación puramente orientados a objetos como Smalltalk . El artículo de Friedman y Wise describía solo futuros explícitos, probablemente reflejando la dificultad de implementar eficientemente futuros implícitos en hardware estándar. La dificultad radica en que el hardware estándar no maneja futuros para tipos de datos primitivos como los enteros. Por ejemplo, una instrucción de suma no sabe cómo manejar . En lenguajes de actor puro u orientados a objetos, este problema se puede resolver enviando el mensaje , que le pide al futuro que se sume a sí mismo y devuelva el resultado. Nótese que el enfoque de paso de mensajes funciona independientemente de cuándo finalice la computación y que no se necesita ninguna restricción/forzamiento.3 + future factorial(100000)future factorial(100000)+[3]3factorial(100000)

El uso de futuros puede reducir drásticamente la latencia en sistemas distribuidos . Por ejemplo, los futuros permiten la canalización de promesas , ^{[ 4 ] [ 5 ]} como se implementa en los lenguajes E y Joule , que también se denominó flujo de llamadas ^{[ 6 ]} en el lenguaje Argus .

Consideremos una expresión que involucre llamadas a procedimientos remotos convencionales , como por ejemplo:

t3 := ( xa() ).c( yb() ) 

que podría ampliarse a

t1 := xa(); t2 := yb(); t3 := t1.c(t2); 

Cada instrucción requiere que se envíe un mensaje y se reciba una respuesta antes de que la siguiente pueda ejecutarse. Supongamos, por ejemplo, que x, y, t1, y t2se encuentran en la misma máquina remota. En este caso, deben realizarse dos viajes de ida y vuelta completos a esa máquina antes de que la tercera instrucción pueda comenzar a ejecutarse. La tercera instrucción provocará entonces otro viaje de ida y vuelta a la misma máquina remota.

Utilizando futuros, la expresión anterior podría escribirse

t3 := (x <- a()) <- c(y <- b()) 

que podría ampliarse a

t1 := x <- a(); t2 := y <- b(); t3 := t1 <- c(t2); 

La sintaxis utilizada aquí es la del lenguaje E, donde x <- a()significa enviar el mensaje a()de forma asíncrona a x. A las tres variables se les asignan inmediatamente futuros para sus resultados, y la ejecución procede a las instrucciones subsiguientes. Los intentos posteriores de resolver el valor de t3pueden causar un retraso; sin embargo, la canalización puede reducir el número de viajes de ida y vuelta necesarios. Si, como en el ejemplo anterior, x, y, t1, y t2están todos ubicados en la misma máquina remota, una implementación en canalización puede calcular t3con un viaje de ida y vuelta en lugar de tres. Debido a que los tres mensajes están destinados a objetos que están en la misma máquina remota, solo es necesario enviar una solicitud y solo es necesario recibir una respuesta que contenga el resultado. El envío t1 <- c(t2)no se bloquearía incluso si t1y t2estuvieran en máquinas diferentes entre sí, o a xo y.

Es importante distinguir entre el procesamiento en paralelo de promesas y el paso de mensajes asíncrono en paralelo. En un sistema que admite el paso de mensajes en paralelo pero no el procesamiento en paralelo, el mensaje enviado x <- a()en y <- b()el ejemplo anterior podría procesarse en paralelo, pero el envío de t1 <- c(t2)tendría que esperar hasta que se recibieran ambos t1mensajes , incluso cuando , , , y se encuentren en la misma máquina remota. La ventaja de latencia relativa del procesamiento en paralelo se vuelve aún mayor en situaciones más complejas que involucran muchos mensajes.t2xyt1t2

Tampoco debe confundirse el procesamiento en paralelo de promesas con el procesamiento de mensajes en paralelo en sistemas de actores, donde es posible que un actor especifique y comience a ejecutar un comportamiento para el siguiente mensaje antes de haber completado el procesamiento del mensaje actual.

En algunos lenguajes de programación como Oz , E y AmbientTalk , es posible obtener una vista de solo lectura de un futuro, que permite leer su valor cuando se resuelve, pero no permite resolverlo:

• En Oz, el !!operador se utiliza para obtener una vista de solo lectura.
• En E y AmbientTalk, un futuro se representa mediante un par de valores denominado par promesa/resolutor . La promesa representa la vista de solo lectura, y el resolvedor es necesario para establecer el valor del futuro.
• En C++ (desde C++11 ) un std::futureproporciona una vista de solo lectura. El valor se establece directamente mediante un std::promise, o se establece al resultado de una llamada a función mediante std::packaged_tasko std::async.
• En la API Deferred de Dojo Toolkit , a partir de la versión 1.5, un objeto de promesa exclusivo para el consumidor representa una vista de solo lectura. ^{[ 7 ]}
• En Alice ML , los futuros proporcionan una vista de solo lectura , mientras que una promesa contiene tanto un futuro como la capacidad de resolver el futuro ^{[ 8 ] [ 9 ]}
• En .NETSystem.Threading.Tasks.Task<T> representa una vista de solo lectura. La resolución del valor se puede realizar a través de System.Threading.Tasks.TaskCompletionSource<T>.

La compatibilidad con vistas de solo lectura es coherente con el principio de mínimo privilegio , ya que permite restringir la capacidad de establecer el valor a los sujetos que necesitan hacerlo. En un sistema que también admite la canalización, el remitente de un mensaje asíncrono (con resultado) recibe la promesa de solo lectura del resultado, y el destinatario del mensaje recibe el resolvedor.

Algunos lenguajes, como Alice ML , definen futuros asociados a un hilo específico que calcula su valor. ^{[ 9 ]} Este cálculo puede iniciarse de forma inmediata al crearse el futuro o de forma diferida cuando se necesita su valor por primera vez. Un futuro diferido es similar a un thunk , en el sentido de un cálculo diferido.

Alice ML también admite futuros que pueden ser resueltos por cualquier hilo, y los denomina promesas . ^{[ 8 ]} Este uso de promesa es diferente de su uso en E, como se describió anteriormente . En Alice, una promesa no es una vista de solo lectura, y no se admite la canalización de promesas. En cambio, la canalización ocurre de forma natural para futuros, incluidos aquellos asociados con promesas.

Si se accede al valor de una promesa de forma asíncrona, por ejemplo, enviándole un mensaje o esperándola explícitamente mediante una construcción como whenen E, no hay problema en retrasar la espera hasta que la promesa se resuelva antes de recibir el mensaje o finalizar la espera. Este es el único caso que debe considerarse en sistemas puramente asíncronos, como los lenguajes de actores puros.

Sin embargo, en algunos sistemas también puede ser posible intentar acceder de forma inmediata o sincrónica al valor de un futuro. En ese caso, hay que tomar una decisión de diseño:

• El acceso podría bloquear el hilo o proceso actual hasta que se resuelva el problema (posiblemente con un tiempo de espera). Esta es la semántica de las variables de flujo de datos en el lenguaje Oz .
• El intento de acceso síncrono siempre podría indicar un error, por ejemplo, lanzando una excepción . Esta es la semántica de las promesas remotas en E. ^{[ 10 ]}
• Potencialmente, el acceso podría tener éxito si el futuro ya está resuelto, pero señalar un error si no lo está. Esto tendría la desventaja de introducir indeterminismo y la posibilidad de condiciones de carrera , y parece ser una elección de diseño poco común.

Como ejemplo de la primera posibilidad, en C++11 , un hilo que necesita el valor de una promesa puede bloquearse hasta que esté disponible llamando a las funciones miembro wait()`get` o ` get()get`. También se puede especificar un tiempo de espera usando las funciones miembro wait_for()`get` o `get` wait_until()para evitar bloqueos indefinidos. Si la promesa surgió de una llamada a ` get`, std::asyncentonces una espera bloqueante (sin tiempo de espera) puede provocar la invocación síncrona de la función para calcular el resultado en el hilo en espera.

Los futuros son un caso particular de la primitiva de sincronización " eventos ", que solo se pueden completar una vez. En general, los eventos se pueden restablecer a un estado vacío inicial y, por lo tanto, completarse tantas veces como se desee. ^{[ 11 ]}

Una I-var (como en el lenguaje Id ) es un futuro con semántica de bloqueo, tal como se definió anteriormente. Una I-estructura es una estructura de datos que contiene I-vars. Una construcción de sincronización relacionada que puede establecerse varias veces con diferentes valores se denomina M-var . Las M-vars admiten operaciones atómicas para tomar o poner el valor actual, donde tomar el valor también restablece la M-var a su estado vacío inicial . ^{[ 12 ]}

Una variable lógica concurrente es similar a un futuro, pero se actualiza mediante unificación , al igual que las variables lógicas en la programación lógica . Por lo tanto, puede vincularse más de una vez a valores unificables, pero no puede volver a un estado vacío o no resuelto. Las variables de flujo de datos de Oz actúan como variables lógicas concurrentes y también poseen semántica de bloqueo, como se mencionó anteriormente.

Una variable de restricción concurrente es una generalización de las variables de lógica concurrente para admitir la programación lógica con restricciones : la restricción puede restringirse varias veces, lo que indica conjuntos más pequeños de valores posibles. Normalmente, existe una forma de especificar una función diferida que debe ejecutarse cada vez que la restricción se restringe aún más; esto es necesario para admitir la propagación de restricciones .

Las promesas específicas de un hilo pueden implementarse fácilmente en promesas que no sean específicas de un hilo, creando un hilo para calcular el valor al mismo tiempo que se crea la promesa. En este caso, es conveniente devolver una vista de solo lectura al cliente, de modo que solo el hilo recién creado pueda resolver esta promesa.

Para implementar futuros implícitos perezosos específicos de hilo (como los que proporciona Alice ML, por ejemplo) en términos de futuros no específicos de hilo, se necesita un mecanismo para determinar cuándo se necesita por primera vez el valor del futuro (por ejemplo, la WaitNeededconstrucción en Oz ^{[ 13 ]} ). Si todos los valores son objetos, entonces la capacidad de implementar objetos de reenvío transparentes es suficiente, ya que el primer mensaje enviado al reenviador indica que se necesita el valor del futuro.

Las promesas no específicas de un hilo pueden implementarse dentro de promesas específicas de un hilo, siempre que el sistema admita el paso de mensajes, haciendo que el hilo que resuelve la promesa envíe un mensaje al hilo de la promesa. Sin embargo, esto puede considerarse una complejidad innecesaria. En los lenguajes de programación basados ​​en hilos, el enfoque más expresivo parece ser proporcionar una combinación de promesas no específicas de un hilo, vistas de solo lectura y, o bien una construcción WaitNeeded , o bien compatibilidad con el reenvío transparente.

La estrategia de evaluación de futuros, que puede denominarse llamada por futuro , no es determinista: el valor de un futuro se evaluará en algún momento entre su creación y su uso, pero el momento preciso no se determina de antemano y puede variar de una ejecución a otra. El cálculo puede comenzar tan pronto como se crea el futuro ( evaluación inmediata ) o solo cuando se necesita el valor ( evaluación diferida ), y puede suspenderse a mitad de camino o ejecutarse en una sola ejecución. Una vez asignado el valor de un futuro, no se vuelve a calcular en los accesos posteriores; esto es similar a la memorización utilizada en la llamada por necesidad .

AUn futuro perezoso es un futuro que tiene una semántica de evaluación perezosa determinista: el cálculo del valor del futuro comienza cuando se necesita por primera vez, como en el caso de la llamada por necesidad. Los futuros perezosos son útiles en lenguajes cuya estrategia de evaluación no es perezosa por defecto. Por ejemplo, enC++11,estos futuros perezosos se pueden crear pasando lastd::launch::deferredpolítica de lanzamiento astd::async, junto con la función para calcular el valor.

En el modelo de actor, una expresión de la forma future <Expression>se define por cómo responde a un Evalmensaje con el entorno E y el cliente C de la siguiente manera: La expresión futura responde al Evalmensaje enviando al cliente C un actor F recién creado (el proxy para la respuesta de la evaluación <Expression>) como valor de retorno simultáneamente con el envío <Expression>de un Evalmensaje con el entorno E y el cliente C. El comportamiento predeterminado de F es el siguiente:

• Cuando F recibe una solicitud R , comprueba si ya ha recibido una respuesta (que puede ser un valor de retorno o una excepción lanzada) tras evaluar <Expression>el procedimiento de la siguiente manera:
  1. Si ya tiene una respuesta V , entonces
     • Si V es un valor de retorno, entonces se envía la solicitud R.
     • Si V es una excepción , entonces se lanza al cliente de la solicitud R.
  2. Si aún no tiene una respuesta, entonces R se almacena en la cola de solicitudes dentro de F.
• Cuando F recibe la respuesta V de la evaluación <Expression>, entonces V se almacena en F y
  • Si V es un valor de retorno, entonces todas las solicitudes en cola se envían a V.
  • Si V es una excepción, se lanza al cliente de cada una de las solicitudes en cola.

Sin embargo, algunas promesas pueden manejar las solicitudes de maneras especiales para proporcionar mayor paralelismo. Por ejemplo, la expresión 1 + future factorial(n)puede crear una nueva promesa que se comportará como el número 1+factorial(n). Este truco no siempre funciona. Por ejemplo, la siguiente expresión condicional:

if m>future factorial(n) then print("bigger") else print("smaller")

se suspende hasta que el futuro factorial(n)haya respondido a la solicitud preguntando si mes mayor que él mismo.

Las construcciones de futuro y/o promesa se implementaron por primera vez en lenguajes de programación como MultiLisp y Act 1. El uso de variables lógicas para la comunicación en lenguajes de programación lógica concurrente fue bastante similar a los futuros. Estos comenzaron en Prolog con Freeze e IC Prolog , y se convirtieron en una verdadera primitiva de concurrencia con Relational Language, Concurrent Prolog , cláusulas Horn protegidas (GHC), Parlog , Strand , Vulcan , Janus , Oz-Mozart , Flow Java y Alice ML . La variable I de asignación única de los lenguajes de programación de flujo de datos , originada en Id e incluida en Concurrent ML de Reppy , es muy similar a la variable lógica concurrente.

La técnica de enrutamiento de promesas (que utiliza futuros para superar la latencia) fue inventada por Barbara Liskov y Liuba Shrira en 1988, ^{[ 6 ]} e independientemente por Mark S. Miller , Dean Tribble y Rob Jellinghaus en el contexto del Proyecto Xanadu alrededor de 1989. ^{[ 14 ]}

El término promesa fue acuñado por Liskov y Shrira, aunque ellos se referían al mecanismo de procesamiento en paralelo con el nombre de flujo de llamadas , que ahora se usa muy poco.

Tanto el diseño descrito en el artículo de Liskov y Shrira como la implementación de la canalización de promesas en Xanadu tenían la limitación de que los valores de las promesas no eran de primera clase : un argumento para, o el valor devuelto por una llamada o envío no podía ser directamente una promesa (por lo que el ejemplo de canalización de promesas dado anteriormente, que usa una promesa para el resultado de un envío como argumento para otro, no habría sido directamente expresable en el diseño de flujo de llamadas ni en la implementación de Xanadu). Parece que las promesas y los flujos de llamadas nunca se implementaron en ninguna versión pública de Argus, ^{[ 15 ]} el lenguaje de programación utilizado en el artículo de Liskov y Shrira. El desarrollo de Argus se detuvo alrededor de 1988. ^{[ 16 ]} La implementación de la canalización de promesas de Xanadu solo estuvo disponible públicamente con la publicación del código fuente de Udanax Gold ^{[ 17 ]} en 1999, y nunca se explicó en ningún documento publicado. ^{[ 18 ]} Las implementaciones posteriores en Joule y E admiten promesas y resolutores de primera clase completos.

Varios lenguajes de actores primitivos, incluida la serie Act, ^{[ 19 ] [ 20 ]} admitían tanto el paso de mensajes en paralelo como el procesamiento de mensajes en paralelo, pero no el procesamiento en paralelo de promesas. (Aunque técnicamente es posible implementar la última de estas características en las dos primeras, no hay evidencia de que los lenguajes Act lo hicieran).

Después del año 2000, se produjo un importante resurgimiento del interés por los futuros y las promesas, debido a su uso en la capacidad de respuesta de las interfaces de usuario y en el desarrollo web , debido al modelo de solicitud-respuesta de paso de mensajes. Varios lenguajes principales ahora tienen soporte de lenguaje para futuros y promesas, popularizados de manera más notable por FutureTaskJava 5 (anunciado en 2004) ^{[ 21 ]} y las construcciones async/await en .NET 4.5 (anunciado en 2010, lanzado en 2012) ^{[ 22 ] [ 23 ]} inspirados en gran medida por los flujos de trabajo asíncronos de F#, ^{[ 24 ]} que data de 2007. ^{[ 25 ]} Esto ha sido posteriormente adoptado por otros lenguajes, en particular Dart (2014), ^{[ 26 ]} Python (2015), ^{[ 27 ]} Hack (HHVM) y borradores de ECMAScript 7 (JavaScript), Scala y C++ (2011).

Algunos lenguajes de programación admiten futuros, promesas, variables de lógica concurrente, variables de flujo de datos o variables I, ya sea mediante soporte directo del lenguaje o en la biblioteca estándar.

• Async/await
• Fibra (informática)
• Futex
• Pirámide de la perdición (programación) , un antipatrón de diseño evitado por las promesas.

• Presentación sobre patrones de concurrencia en ScaleConf.
• Generación de valor futuro y potencial en el repositorio de patrones de Portland
• Programación en cadena sencilla con Futures en Python