In cosa consiste l'uso corretto dei thread nella programmazione?

you should use only one thread per processor,

Forse in HPC dove vuoi la massima efifcienza - ma per il resto la cosa più stupida che ho sentito oggi!

Dovresti utilizzare il numero di thread appropriati per la progettazione del programma e dare comunque prestazioni accettabili.

Per un server web potrebbe essere ragionevole attivare un thread per ogni connessione in ingresso (sebbene ci siano modi migliori per i server con carichi pesanti).

Per un ide ogni strumento in esecuzione nella propria thread non è irragionevole. Sospetto che molti dei thread segnalati per l'IDE Net siano cose come la registrazione e le attività di I / O che vengono avviate nei propri thread in modo che possano continuare a essere sbloccati.

Il consiglio di un thread-per-core si applica quando lo scopo è la velocità attraverso l'esecuzione parallela.

Una ragione completamente diversa e ugualmente valida è la semplicità del codice quando deve rispondere a eventi imprevedibili. Quindi, se un programma deve ascoltare 100 socket e sembra prestare la massima attenzione a ciascuno di essi, è perfetto per il threading. Un altro esempio è un'interfaccia utente, in cui un thread gestisce gli eventi dell'interfaccia utente, mentre un altro esegue l'elaborazione in background.

Vuoi un thread per ogni computazione che può procedere a velocità diverse rispetto ad altri calcoli.

Per il calcolo parallelo associato alla CPU, che ha grossi blocchi di lavoro, in genere si desidera un thread per CPU, perché una volta che sono tutti occupati, altri thread non aiutano e creano semplicemente un sovraccarico dello scheduler. Se i blocchi di lavoro hanno dimensioni irregolari nel tempo o sono generati dinamicamente in fase di esecuzione (spesso accade quando si elaborano grandi strutture di dati complesse), è possibile collegare questi blocchi a molti thread, in modo che uno scheduler abbia sempre un grande impostato per scegliere quando completare un blocco di lavoro, per mantenere tutte le CPU occupate.

Per il calcolo I / O associato, generalmente si desidera un thread per ciascun "canale" I / O indipendente poiché essi comunicano a velocità diverse e i thread bloccati sul canale non impediscono ad altri thread di fare progressi.

La regola empirica per i thread è, si vuole almeno un thread di lavoro "attivo" (in grado di avere i suoi comandi eseguiti immediatamente dato CPU) per ogni "unità di esecuzione" disponibile sul computer. Una "unità di esecuzione" è un processore di istruzioni logiche, quindi un server iperthreaded Xeon quad-core e quad-core avrebbe 32 EU (4 chip, 4 core per chip, ciascuno hyperthreaded). Il tuo Core i7 medio avrebbe 8.

Un thread per UE è l'uso più completo della potenza della CPU, a condizione che i thread siano sempre in esecuzione; questo non è quasi mai il caso, poiché i thread devono accedere alla memoria non memorizzata nella cache, al disco rigido, alle porte di rete, ecc. che devono attendere e che non richiedono l'attenzione attiva della CPU. In questo modo è possibile aumentare ulteriormente l'efficienza generale con più thread in coda e molto rari. Questo ha un costo; quando una CPU cambia un thread, deve memorizzare nella cache i registri del thread, il puntatore di esecuzione e altre informazioni di stato normalmente conservate nei meccanismi interni di un'UE e molto rapidamente accessibili, consentendo ad altre EU in quel chip CPU di raccoglierlo. Richiede inoltre thread nel sistema operativo per decidere su quale thread deve essere attivato. Infine, quando una UE cambia argomento, perde i guadagni in termini di prestazioni del pipelining utilizzato dalla maggior parte delle architetture dei processori; deve lavare la pipeline prima di passare ai fili. Tuttavia, poiché tutto ciò richiede in media molto meno tempo del semplice attesa del disco rigido o persino della RAM per tornare indietro con le informazioni, ne vale la pena.

Tuttavia, in generale, una volta superato il doppio del numero di thread "attivi" come UE, il sistema operativo inizia a spendere più thread di pianificazione temporale dell'UE, e gli EU passano più tempo a passare da loro, rispetto a quelli effettivamente spesi esecuzione di thread attivi di programmi. Questo è il punto delle diseconomie di scala; a questo punto sarà necessario più tempo per l'esecuzione di un algoritmo multithread se si aggiungesse un thread aggiuntivo.

Quindi, nel complesso, si desidera mantenere almeno il numero di thread nel proprio programma rispetto a quelli dell'UE sul computer, ma si desidera evitare di avere più del doppio di quel numero che non è in attesa o in attesa.

Dovresti usare un thread per:

Ogni processore che devi tenere occupato.

Ogni I / O può essere utile in modo concorrente che non è possibile eseguire in modo non bloccante. (Ad esempio, legge da un disco locale.)

Ogni attività che richiede un thread dedicato, ad esempio la chiamata in una libreria che non ha un'interfaccia non bloccante o in cui le interfacce non bloccanti non sono appropriate. Ciò include attività come il monitoraggio dell'orologio di sistema, i timer di accensione e così via.

Alcuni extra per proteggersi da blocchi imprevisti come errori di pagina.

Alcuni extra per proteggersi dai blocchi previsti che non vale la pena di ottimizzare, ad esempio nel codice non critico. (Ad esempio, se molto raramente hai bisogno di fare una richiesta DNS, probabilmente non vale la pena di fare richieste DNS in modo asincrono. Crea solo alcuni thread aggiuntivi e rendi la vita più facile.)

Se segui la regola "un thread per processore", tutto il tuo codice è critico per le prestazioni. Qualsiasi codice che blocchi per qualche motivo indica che il tuo processo non può utilizzare quel processore. Ciò rende la programmazione molto più difficile senza una buona ragione.

È possibile generare processi e thread per abilitare l'utilizzo di un sistema multiprocessore multiprocessore per un singolo programma, nel qual caso non si ottiene alcun vantaggio (per il singolo programma almeno) dall'avere più thread \ processi quindi core.

Oppure puoi avere routine che eseguono il polling di un evento che in genere bloccano l'ulteriore esecuzione. Piuttosto quindi legare la CPU con il polling, puoi invece creare un thread che siederà in uno stato inattivo finché l'evento appropriato non lo riattiva. Questo metodo è molto comunemente utilizzato nei server Web e nelle code degli eventi della GUI. La maggior parte dei programmi desidera avere una sorta di archivio dati centrale (anche se il suo codice di esecuzione del programma) a cui tutti i thread possono accedere, quindi suppongo sia per questo che usano il threading sui processi.

Le app che citi raramente eseguono tutte quelle decine di thread contemporaneamente. Molti di loro siedono lì perché si trovano in un pool di thread . L'app invia varie attività a una coda, che viene eliminata dai thread nel pool di thread.

Perché la piscina è così grande? Perché spesso i thread devono attendere per altre risorse come disco, rete, utente, qualche altro thread, ecc. Mentre un thread è in attesa, è opportuno eseguire altri thread per utilizzare completamente il processore. Ridimensionare la piscina in modo appropriato è complicato, però. Troppi thread e perderai le prestazioni perché il processore non è completamente utilizzato durante l'attesa di qualcosa. Troppi thread e perderai le prestazioni a causa del passaggio da uno all'altro.