2012-02-11 14 views
9

std :: async tiene una sobrecarga que toma una política std :: launch como primer argumento. ¿Cuándo debería usar esta sobrecarga? ¿Cuáles son las diferentes políticas disponibles? (Creo que la sincronización y la asincrónica son las dos opciones). ¿Cuándo debería usar la política de sincronización? ¿Cómo es eso diferente de ejecutarlo directamente?¿Cuándo debería usar std :: async con sync como política?

+2

http://www.justsoftwaresolutions.co.uk/threading/multithreading-in-c++0x-part-8-futures-and-promises.html ---> Esto podría ser útil – Jagannath

Respuesta

5

Resumen de the very helpful article that Jagannath linked, y comentarios sobre los posibles usos.

Hay 3 políticas de lanzamiento:

  • any: la biblioteca decide si se debe generar un hilo de una o no
  • async: pedir explícitamente un hilo para ser generado
  • deferred: que de forma explícita pida un hilo no engendrado

Por lo tanto, elLa políticaes una forma de obtener evaluación perezosa determinista (también conocida como llamada por necesidad). Por ejemplo, suponga que tiene:

void MyClass::lazy(std::future<int> const& f) { 
    if (this->notReady()) { return; } 
    if (this->stillNotReady()) { return; } 
    if (this->value() == 42) { return; } 

    this->go(f.get()); 
} 

Ahora bien, si el cálculo del valor de este número entero es largo (por ejemplo, puede invocar un ida y vuelta de red), entonces es un poco derrochador para calcular en todo el casos que realmente no lo requieren ... ¡y ahora tenemos la herramienta para hacerlo!

void func(MyClass& mc) { 
    std::future<int> f = std::async(std::launch::deferred, []() { 
         return stoi(memcached.get("KEY")); 
         }); 

    mc.lazy(f); 
} 

Tenga en cuenta que esto es sutilmente diferente del uso de un std::function<int()> (y un cierre), porque el cálculo se realiza una vez por todas, garantizando que las llamadas posteriores para obtener siempre devuelven el mismo resultado.

La diferencia con las otras políticas también se puede expresar en términos de si la operación se realiza cuando no necesita el valor.

  • any: podría ser realizado en otro hilo (proactiva) o no se realiza en absoluto
  • async: se llevará a cabo en otro hilo
  • deferred: se no realizarse

Por lo tanto, deferred le da un mejor control, que es importante si la llamada tiene un efecto secundario.

+1

"sync" es de hecho 'std :: launch :: deferred' – Cubbi

+0

@Cubbi: gracias por señalar, debería haber verificado con el estándar. –

+0

"las llamadas subsiguientes a' get() '" invocarán un comportamiento indefinido, ya que 'get()' invalida el 'futuro'. Necesitarías un 'shared_future' para evitar la invalidación. –

Cuestiones relacionadas