Come si aggiungono automaticamente i thread a un pool in base alle esigenze di calcolo del programma?

Question

Abbiamo un programma C++ che, a seconda del modo in cui l'utente lo configura, potrebbe essere legato alla CPU o vincolato all'IO. Allo scopo di un accoppiamento lento con la configurazione del programma, vorrei che il mio pool di thread si realizzasse automaticamente quando il programma trarrebbe beneficio da più thread (cioè vincolati dalla CPU). Sarebbe bello se si rendesse conto di quando era I/O vincolato e ridotto il numero di lavoratori, ma sarebbe solo un bonus (cioè sarei felice con qualcosa che cresce automaticamente senza il ritiro automatico).

Usiamo Boost quindi se c'è qualcosa che potrebbe aiutarci possiamo usarlo. Mi rendo conto che qualsiasi soluzione sarebbe probabilmente specifica per la piattaforma, quindi siamo principalmente interessati a Windows e Linux, con un interesse terziario in OS X o in qualsiasi altro * nix.

Answer 1

Risposta breve: utilizzare pool di thread distinti di dimensioni fisse per operazioni intensive della CPU e per I/O. Oltre alle dimensioni del pool, l'ulteriore regolazione del numero di thread attivi verrà eseguita dal buffer limitato (Producer/Consumer) che sincronizza il computer e le fasi IO del flusso di lavoro.

Per problemi di calcolo e di dati in cui i colli di bottiglia sono una destinazione mobile tra diverse risorse (ad esempio CPU vs IO), può essere utile fare una chiara distinzione tra un thread e un thread, in particolare, come prima approssimazione:

• un filo che viene creato per utilizzare più cicli di CPU ("filo CPU")
• un filo che viene creato per gestire un'operazione asincrona IO ("filo IO")

Più in generale, i thread dovrebbero essere separati da il tipo di risorse di cui hanno bisogno. Lo scopo dovrebbe essere quello di garantire che un singolo thread non utilizzi più di una risorsa (ad esempio evitando di passare dalla lettura dei dati all'elaborazione dei dati nello stesso thread). Quando un battistrada utilizza più di una risorsa, dovrebbe essere diviso e i due thread risultanti dovrebbero essere sincronizzati attraverso un buffer limitato.

In genere, per saturare le pipeline di istruzioni di tutti i core disponibili sul sistema dovrebbero esserci esattamente i thread CPU necessari. Per garantire ciò, è sufficiente disporre di un "pool di thread della CPU" con esattamente tutti i thread dedicati esclusivamente al lavoro di calcolo. Sarebbe boost:: o std::thread::hardware_concurrency() se ci si può fidare di questo. Quando l'applicazione ha bisogno di meno, ci saranno semplicemente thread inutilizzati nel pool di thread della CPU. Quando ha bisogno di più, il lavoro è in coda. Invece di un "pool di thread della CPU", è possibile utilizzare C++ 11 std::async ma è necessario implementare un meccanismo di limitazione del thread con la selezione degli strumenti di sincronizzazione (ad esempio un semaforo di conteggio).

Oltre al "pool di thread della CPU", può esistere un altro pool di thread (o diversi altri pool di thread) dedicato alle operazioni di I/O asincrone. Nel tuo caso, sembra che la contesa sulle risorse IO sia potenzialmente una preoccupazione. Se questo è il caso (ad esempio un disco rigido locale) il numero massimo di thread deve essere controllato attentamente (ad esempio al massimo 2 thread di lettura e 2 di scrittura su un disco rigido locale). Questo è concettualmente lo stesso dei thread della CPU e si dovrebbe avere un pool di thread di dimensioni fisse per la lettura e un altro per la scrittura. Sfortunatamente, probabilmente non ci sarà alcuna buona primitiva disponibile per decidere sulla dimensione di questi pool di thread (la misurazione potrebbe essere semplice se i tuoi pattern IO sono molto regolari). Se il conflitto di risorse non è un problema (ad esempio, NAS o richieste HTTP piccole), allora boost::asio o C++ 11 std::async sarebbe probabilmente un'opzione migliore di un pool di thread; nel qual caso, la limitazione del filo può essere interamente lasciata ai buffer limitati.