Ha senso generare più di un thread per processore?

Question

Da un punto di vista logico, un'applicazione può richiedere dozzine o centinaia di thread, alcuni dei quali dormiremo la maggior parte del tempo, ma pochi saranno sempre in esecuzione contemporaneamente. La domanda è: ha senso generare più thread concorrenti rispetto ai processori presenti in un sistema, oppure è uno spreco?

Ho visto alcune applicazioni server che implementano uno scheduler per gestire logicamente le attività (spesso chiamate job), ma anche generare molti thread, quindi non vedo dove sia il vantaggio.

Grazie in anticipo.

Answer 1

Sicuro. Se il tuo software fa spesso uso del disco o dell'IO di rete, puoi spesso migliorare il throughput aggiungendo qualche altro thread. Quei thread in più saranno svegli e faranno roba mentre gli altri thread stanno bloccando su IO.

Answer 2

Ogni volta che si dispone di un'attività in attesa di un'operazione di I/O, è opportuno racchiuderla in una discussione e attivarla. C'è una grande probabilità che il thread venga sospeso mentre attende che l'operazione I/O termini. Quando si sveglia, il risultato lo attende.

Answer 3

Perché tutti i sistemi operativi moderni sono multitasking: ogni thread riceve una quota di tempo dal processore. In realtà non è un'esecuzione concomitante, ma dato che il processore è in grado di gestire migliaia di richieste al secondo, si tratta di un'esecuzione concorrente "apparente".

Quindi sì, se il caso ha bisogno, ha senso multi-thread su un singolo processore.

Answer 4

Uno dei vantaggi è quando si aggiorna l'hardware, che probabilmente otterrà più processori/core.

Answer 5

Risposta breve è "sì".

Anche se si potrebbe ottenere di più dal multithreading su un ambiente multiprocessore, è ancora una tecnologia utile su un singolo processore, principalmente perché significa che delegherete del lavoro allo scheduler di processo, che dovrebbe avere molte più informazioni di hai.

Se non multithread, ci si ritroverà per fare il lavoro di pianificazione da soli, che potrebbe essere una buona cosa, se questo è quello che vi serve, ma sarà molto probabilmente essere sia noioso e inefficiente

Answer 6

Questo può rendere senso se

1. i vantaggi programma di progettazione, in quanto si dispone di task paralleli che sono meglio implementate in fili, o

2. alcune delle vostre discussioni sono I/o-bound, in modo da non utilizzare il processori/core per conto proprio.

Answer 7

Altri hanno parlato di situazioni in cui ha quasi certamente senso (quando si sta facendo un IO qualsiasi lento).

Potrebbe Non essere una buona idea se:

• le discussioni che stanno facendo CPU bound lavoro

e

• i fili ciascuno desidera utilizzare un sacco (cioè significativo rispetto alla dimensione della cache) di memoria che non si sovrappone a

In questo caso c'è la possibilità di causare errori di cache non necessari.

Answer 8

Ho scoperto che durante la scrittura di parser di dati che gestiscono più grandi insiemi di dati su una rete è meglio creare un thread per ogni lettera dell'alfabeto (pertinente ai dati) e ottenere il programma più CPU e memoria limitata . La limitatezza di I/O ereditata dalle operazioni di rete e disco è un collo di bottiglia importante, quindi è possibile anche "iniziare" sugli altri file di dati anziché eseguire il lavoro in sequenza.

Su un quad core, avrebbe sicuramente senso iniziare più di quattro thread. È improbabile che quei 4 fili siano distribuiti su più di uno dei core, specialmente con le attuali velocità del processore.

Answer 9

Secondo Herb Sutter (uno dei massimi esperti di concorrenza), uno dei Pillars of Concurrency è Reattività e isolamento attraverso agenti asincroni. Il sommario è:

Restare reattivo eseguendo attività in modo indipendente e attività in modo asincrono, comunicando tramite messaggi.

Grande articolo (e la serie nel suo insieme!). Sto ancora aspettando il libro.