Quando dovrei usare std :: async con sincronizzazione come criterio?

Question

std :: async ha un overload che accetta un criterio std :: launch come primo argomento. Quando dovrei usare questo sovraccarico? quali sono le diverse politiche disponibili? (Penso che la sincronizzazione e l'asincrono siano le due opzioni). Quando dovrei usare la politica di sincronizzazione? In che modo è diverso dal gestirlo direttamente?

Answer 1

Riepilogo da the very helpful article that Jagannath linked e commenti sui possibili usi.

Ci sono 3 le politiche di lancio:

• any: la libreria sceglie se genera un thread di un o no
• async: si chiede in modo esplicito per un filo da generato
• deferred: in modo esplicito chiedere una discussione non da generare spa

Pertanto, ilLa politicaè un modo per ottenere la valutazione lenta deterministica (nota anche come chiamata per necessità). Per esempio, supponiamo di avere:

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()); 
} 

Ora, se il calcolo del valore di questo intero è lunga (per esempio, può invocare un andata e ritorno di rete), quindi è un pò uno spreco di calcolare in tutta la casi che non lo richiedono veramente ... e ora abbiamo lo strumento per farlo!

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

    mc.lazy(f); 
} 

noti che questo è leggermente diverso da utilizzando un std::function<int()> (e chiusura), perché il calcolo è fatto volta per tutte, garantendo che le chiamate successive per ottenere sempre lo stesso risultato.

La differenza con le altre politiche può anche essere espressa in termini di se l'operazione viene eseguita quando non è necessario il valore.

• any: potrebbe essere eseguita su un altro thread (proattivo) o non eseguita affatto
• async: verranno eseguiti su un altro thread
• deferred: si non essere eseguite

Pertanto, deferred offre un controllo migliore, che è importante se la chiamata ha un effetto collaterale.