Llamadas asíncronas
La forma de llamar a métodos que hasta ahora se ha explicado realiza la llamada de manera síncrona, lo que significa que la instrucción siguiente a la llamada no se ejecuta hasta que no finalice el método llamado. Sin embargo, a todo método almacenado en un objeto delegado también es posible llamar de manera asíncrona a través de los métodos del mismo, lo que consiste en que no se espera a que acabe de ejecutarse para pasar a la instrucción siguiente a su llamada sino que su ejecución se deja en manos de un hilo aparte que se irá ejecutándolo en paralelo con el hilo llamante.
Por tanto los delegados proporcionan un cómodo mecanismo para ejecutar cualquier método asíncronamente, pues para ello basta introducirlo en un objeto delegado del tipo apropiado. Sin embargo, este mecanismo de llamada asíncrona tiene una limitación, y es que sólo es válido para objetos delegados que almacenen un único método.
Para hacer posible la realización de llamadas asíncronas, aparte de los métodos heredados de System.MulticastDelegate todo delegado cuenta con estos otros dos que el compilador define a su medida en la clase en que traduce la definición de su tipo:
IAsyncResult BeginInvoke(<parámetros>, AsyncCallback cb, Object o)
<tipoRetorno> EndInvoke(<parámetrosRefOut>, IASyncResult ar)
|
BeginInvoke() crea un hilo que ejecutará los métodos almacenados en el objeto delegado sobre el que se aplica con los parámetros indicados en <parámetros> y devuelve un objeto IAsyncResult que almacenará información relativa a ese hilo (por ejemplo, a través de su propiedad de sólo lectura bool IsComplete puede consultarse si ha terminado su labor) Sólo tiene sentido llamarlo si el objeto delegado sobre el que se aplica almacena un único método, pues si no se lanza una System.ArgumentException.
El parámetro cb de BeginInvoke() es un objeto de tipo delegado que puede almacenar métodos a ejecutar cuando el hilo antes comentado finalice su trabajo. A estos métodos el CLR les pasará automáticamente como parámetro el IAsyncResult devuelto por BeginInvoke(), estando así definido el delegado destinado a almacenarlos:
public delegate void ASyncCallback(IASyncResult obj);
|
Por su parte, el parámetro o de BeginInvoke puede usarse para almacenar cualquier información adicional que se considere oportuna. Es posible acceder a él a través de la propiedad object AsyncState del objeto IAsyncResult devuelto por BeginInvoke()
En caso de que no se desee ejecutar ningún código especial al finalizar el hilo de ejecución asíncrona o no desee usar información adicional, puede darse sin ningún tipo de problema el valor null a los últimos parámetros de BeginInvoke() según corresponda.
Finalmente, EndInvoke() se usa para recoger los resultados de la ejecución asíncrona de los métodos iniciada a través BeginInvoke() Por ello, su valor de retorno es del mismo tipo que los métodos almacenables en el objeto delegado al que pertenece y en <parámetrosRefOut> se indican los parámetros de salida y por referencia de dichos métodos. Su tercer parámetro es el IAsyncResult devuelto por el BeginInvoke() que creó el hilo cuyos resultados se solicita recoger y se usa precisamente para identificarlo. Si ese hilo no hubiese terminado aún de realizar las llamadas, se esperará a que lo haga.
Para ilustrar mejor el concepto de llamadas asíncronas, el siguiente ejemplo muestra cómo encapsular en un objeto delegado un método F() para ejecutarlo asíncronamente:
D objDelegado = new D (F);
IAsyncResult hilo = objDelegado.BeginInvoke(3,
new AsyncCallback(M),
"prueba");
// ... Hacer cosas
objDelegado.EndInvoke(hilo);
|
Donde el método M ha sido definido en la misma clase que este código así:
public static void M(IAsyncResult obj)
{
Console.WriteLine("Llamado a M() con {0}", obj.AsyncState);
}
|
Si entre el BeginInvoke() y el EndInvoke() no hubiese habido ninguna escritura en pantalla, la salida del fragmento de código anterior sería:
|
Pasado valor 3 a F()
Llamado a M() con prueba
|
La llamada a BeginInvoke() lanzará un hilo que ejecutará el método F() almacenado en objDelegado, pero mientras tanto también seguirá ejecutándose el código del hilo desde donde se llamó a BeginInvoke() Sólo tras llamar a EndInvoke() se puede asegurar que se habrá ejecutado el código de F(), pues mientras tanto la evolución de ambos hilos es prácticamente indeterminable ya que depende del cómo actúe el planificador de hilos.
Aún si el hilo llamador modifica el valor de alguno de los parámetros de salida o por referencia de tipos valor, el valor actualizado de éstos no será visible para el hilo llamante hasta no llamar a EndInvoke() Sin embargo, el valor de los parámetros de tipos referencia sí que podría serlo. Por ejemplo, dado un código como:
int x=0;
Persona p = new Persona("Josan", "7361928-E", 22);
IAsyncResult res = objetoDelegado.BeginInvoke(ref x, p, null, null);
// Hacer cosas...
objetoDelegado.EndInvoke(ref x, res);
|
Si en un punto del código comentado con // Hacer cosas..., donde el hilo asíncrono ya hubiese modificado los contenidos de x y p, se intentase leer los valores de estas variables, sólo se leería el valor actualizado de p. El de x no se vería hasta después de la llamada a EndInvoke()
Por otro lado, hay que señalar que si durante la ejecución asíncrona de un método se produce alguna excepción, ésta no sería notificada pero provocaría que el hilo asíncrono abortase. Si posteriormente se llamase a EndInvoke() con el IAsyncResult asociado a dicho hilo, se relanzaría la excepción que produjo el aborto y entonces podría tratarse.
Para optimizar las llamadas asíncronas es recomendable marcar con el atributo OneWay definido en System.Runtime.Remoting.Messaging los métodos cuyo valor de retorno y valores de parámetros de salida no nos importen, pues ello indica a la infraestructura encargada de hacer las llamadas asíncronas que no ha de considerar. Por ejemplo:
[OneWay] public void Método()
{}
|
Ahora bien, hay que tener en cuenta que hacer esto implica perder toda posibilidad de tratar las excepciones que pudiese producirse al ejecutar asíncronamente el método atribuido, pues con ello llamar a EndInvoke() dejaría de relanzar la excepción producida.
Por último, a modo de resumen a continuación se indican cuáles son los patrones que pueden seguirse para recoger los resultados de una llamada asíncrona:
- Detectar si la llamada asíncrona ha finalizado mirando el valor de la propiedad IsComplete del objeto IAsyncResult devuelto por BeginInvoke() Cuando sea así, con EndInvoke() puede recogerse sus resultados.
- Pasar un objeto delegado en el penúltimo parámetro de BeginInvoke() con el método a ejecutar cuando finalice el hilo asíncrono, lo que liberaría al hilo llamante de la tarea de tener que andar mirando si ha finalizado o no.
Si desde dicho método se necesitase acceder a los resultados del método llamado podría accederse a ellos a través de la propiedad AsyncDelegate del objeto IAsyncResult que recibe. Esta propiedad contiene el objeto delegado al que se llamó, aunque se muestra a continuación antes de acceder a ella hay que convertir el parámetro IAsyncResult de ese método en un AsyncResult:
public static void M(IAsyncResult iar)
{
D objetoDelegado = (D) ((AsyncResult iar)).AsyncDelegate;
// A partir de aquí podría llamarse a EndInvoke()
// a través de objetoDelegado
}
|
|