Quale limite di std :: async si riferisce a Stroustrup?

Question

Nel capitolo "tutorial" 5.3.5.3 del suo libro Il linguaggio di programmazione C++ (4a edizione), Bjarne Stroustrup scrive sulla funzione std::async.

C'è un limite evidente: Non pensate nemmeno di usare async() per le attività che il blocco che necessitano di condividere risorse - con async() non si sa nemmeno quanti thread s verrà utilizzato perché è fino a async() decidere in base a ciò che sa sulle risorse di sistema disponibili al momento della chiamata.

Una simile esortazione può essere trovata in the C++11-FAQ on his website.

"Semplice" è l'aspetto più importante della progettazione async()/future; i futures possono anche essere utilizzati con thread in generale, ma nemmeno utilizza async() per avviare attività che eseguono operazioni di I/O, manipola mutex o in altri modi interagiscono con altre attività.

È interessante notare che non approfondisce questa limitazione quando ritorna alle caratteristiche di concorrenza di C++ 11 in maggior dettaglio nel § 42.4.6 del suo libro. Ancora più interessante, in questo capitolo ha effettivamente continua (confronta con la dichiarazione sul suo sito web):

un utilizzo semplice e realistico di async() sarebbe quello di generare un compito di raccogliere l'input da un utente.

The documentation of async on cppreference.com non menziona affatto tali limitazioni.

Dopo aver letto alcune proposte e discussioni che portano allo standard C++ 11 nella sua forma finale (che sfortunatamente non ho accesso a), capisco che async è stato incorporato molto tardi nello standard C++ 11 e c'è stata molta discussione su quanto questa funzione dovrebbe essere potente. In particolare, ho trovato l'articolo Async Tasks in C++11: Not Quite There Yet by Bartosz Milewski un ottimo riassunto dei problemi che devono essere considerati quando si implementa async.

Tuttavia, tutti i problemi discussi sono riportate thread_local variabili che non vengono distrutti se un thread viene riciclato, bloccaporte spuri o violazioni di accesso ai dati se un thread cambia il suo compito metà azione e entrambi i compiti tenere una mutex o recursive_mutex rispettivamente, e così via. Queste sono serie preoccupazioni per gli implementatori della funzionalità, ma se ho capito bene, la specifica corrente di async richiede che tutti questi dettagli siano nascosti all'utente eseguendo l'attività sul thread del chiamante o come se un nuovo thread sia stato creato per il compito.

Quindi la mia domanda è: Cosa non mi è concesso a che fare con async che mi è permesso di fare utilizzando thread s manualmente e qual è il motivo di questa limitazione?

Ad esempio, c'è qualcosa di sbagliato nel seguente programma?

#include <future> 
#include <iostream> 
#include <mutex> 
#include <vector> 

static int tally {}; 
static std::mutex tally_mutex {}; 

static void 
do_work(const int amount) 
{ 
    for (int i = 0; i < amount; ++i) 
    { 
     // Might do something actually useful... 
     const std::unique_lock<std::mutex> lock {tally_mutex}; 
     tally += 1; 
    } 
} 

int 
main() 
{ 
    constexpr int concurrency {10}; 
    constexpr int amount {1000000}; 
    std::vector<std::future<void>> futures {}; 
    for (int t = 0; t < concurrency; ++t) 
    futures.push_back(std::async(do_work, amount/concurrency)); 
    for (auto& future : futures) 
    future.get(); 
    std::cout << tally << std::endl; 
} 

Ovviamente, se il runtime decide di pianificare tutte le attività sul thread principale, ci sarà inutilmente acquisire il mutex più e più volte senza una buona ragione. Ma mentre questo potrebbe essere inefficiente, non è errato.

Answer 1

Il "problema" con std :: async è che per impostazione predefinita non si sa se inizia o meno una discussione. Se la tua funzione deve essere eseguita su un thread separato, questo è un problema poiché la tua funzione potrebbe non funzionare finché non viene chiamato get() o wait(). È possibile passare std :: launch :: async per assicurarsi che la funzione venga avviata sul proprio thread, che è come un file std :: thread che non può essere staccato da BG.

Answer 2

Hai appuntito il problema. I fili possono essere riciclati ... Quindi qualsiasi utilizzo dello storage thread_local è pericoloso.

Il tuo ciclo è solo - ma, come hai detto, potrebbe essere inefficiente.

È possibile richiedere alla lingua di produrre un altro thread utilizzando std :: launch :: async. Ma i thread potrebbero ancora essere riciclati.