Come posso sapere se utilizzo in modo eccessivo il multi-threading?


15

Al momento mi sento come se stessi usando il multi-threading.

Ho 3 tipi di dati, A, B e C.

Ciascuno Apuò essere convertito in più se Bciascuno Bpuò essere convertito in più se C.

Mi interessa solo trattare Cs.

Potrei scriverlo abbastanza facilmente con un paio di funzioni di conversione. Ma mi sorpresi attuazione con fili, tre code ( queue_a, queue_be queue_c). Esistono due thread che eseguono le diverse conversioni e un lavoratore:

  • ConverterAlegge queue_ae scrive aqueue_b
  • ConverterBlegge queue_be scrive aqueue_c
  • Worker gestisce ogni elemento da queue_c

Le conversioni sono abbastanza banali e non so se questo modello sia troppo contorto. Ma mi sembra estremamente robusto. Ogni "convertitore" può iniziare a funzionare anche prima che i dati arrivino nelle code e in qualsiasi momento nel codice posso semplicemente "inviare" nuovi messaggi Ae Battiverà la pipeline di conversione che a sua volta attiverà un lavoro da parte del lavoratore filo.

Anche il codice risultante sembra più semplice. Ma non sono ancora sicuro se sto abusando dei thread per qualcosa di semplice.


5
Penso che questa domanda debba essere accorciata un po 'per andare a caccia. Anche il titolo è fuorviante: sembra che stai per lanciarti in un rant (anche se non lo sei). Forse dovresti chiedere qualcosa di più vicino a "Come posso sapere se uso eccessivamente il multithreading?"
KChaloux,

@KChaloux Sono d'accordo. L'ho modificato e spero che catturi i miei pensieri un po 'meglio.
exhuma,

4
@exhuma Awesome. Il tuo -1 diventa +1
KChaloux il

3
@KChaloux ... la differenza che una visita al gabinetto può fare al tuo processo
mentale

Questo libro PDF online, Manuale per l'ottimizzazione della maturità (appena pubblicato giorni fa) parla degli effetti sistematici in cui l'impatto di un modulo sulle prestazioni complessive del sistema a volte può superare la frazione del tempo di esecuzione del modulo.
rwong

Risposte:


16

È quasi sempre più semplice pensare in modo sequenziale e successivamente modificare quella logica per funzionare meglio utilizzando i thread. E, come dice l'espressione, "Se non è rotto, non aggiustarlo". La maggior parte dei programmatori non usa i thread semplicemente perché non è necessario usarli.

Se ti senti più a tuo agio nel usarli, più potenza per te. Tuttavia, sappi che se i thread non offrono un aumento di velocità eliminando i colli di bottiglia, stanno quasi sicuramente rallentando il tuo programma.

Considera anche che i sistemi che dedicano una sola CPU a un processo simuleranno più thread con un singolo thread al fine di risparmiare risorse (ciò non accade spesso con i computer moderni, anche se le applicazioni degli smartphone sono ancora molto soggette a questo abuso). In questo caso, anche se stai eliminando i colli di bottiglia attraverso l'uso dei thread, in realtà sarà più lento che se non utilizzassi affatto i thread.

E, forse la ragione più sottile per usare la cautela per usare i thread, ma certamente non meno importante, i thread hanno la tendenza a fare ciò che non ti aspetti. Sì, se stai prendendo precauzioni, dovresti stare bene. Sì, se i tuoi thread non scrivono su variabili condivise tra thread, dovresti essere a posto. Detto questo, i bug relativi al thread sono molto difficili da trovare. Dal momento che sono dell'idea che un programmatore non possa mai eliminare completamente la possibilità di creare bug nel codice e quindi un programmatore dovrebbe prendere misure per proteggersi da possibili bug piuttosto che concentrarsi sulla loro eliminazione completa, dovresti sicuramente applicare questa idea a hard- per trovare anche i bug dei thread. In altre parole, sappi che nonostante i tuoi migliori sforzi,

Quindi dovresti usare le discussioni comunque? Bene, una sana conoscenza dei thread non è certamente una cosa negativa, specialmente se diventi bravo a farlo. Tuttavia, il movimento degli ultimi tempi è stato verso linguaggi a thread singolo come node.js. Uno dei principali vantaggi di avere un singolo thread è che è facile da ridimensionare e alcune ottimizzazioni possono essere fatte se sai che le istruzioni dovrebbero essere eseguite in sequenza (anche se le ottimizzazioni possono significare che le istruzioni che possono essere eseguite in parallelo possono essere eseguito in modo asincrono).

Detto questo, dico di fare ciò che è più comodo per te. Nella mia esperienza, scrivere un programma che hai capito ha una priorità maggiore rispetto a farlo funzionare più velocemente. Assicurati di usare i thread quando pensi che ti aiuti a scrivere il programma e non perché vuoi che funzioni più velocemente, dal momento che non dovresti preoccuparti così tanto delle prestazioni mentre scrivi il programma (l'ottimizzazione è importante, ma posso anche aspettare).


Stai facendo punti interessanti. Nel mio caso, la pipeline di conversione non riguarda le prestazioni. Si tratta di semplicità / leggibilità del codice. Il thread di lavoro è circa la prestazione. Ogni attività finale viene eseguita su un computer remoto e l'invio di più lavori ne consente l'esecuzione in modo significativamente più veloce.
exhuma,

2
@exhuma Oltre all'esecuzione parallela tramite più thread, è possibile utilizzare anche tecniche asincrone come Futures / Promises o uno stile orientato al callback. Si noti che è possibile modellare pipeline concatenando iteratori / flussi; non è necessario utilizzare effettivamente i thread, tranne se si desidera utilizzare più CPU (nel codice di rete, questo non è quasi mai il caso)
amon

@exhuma Sì, i thread aiutano le prestazioni in generale. Il mio punto era che se non lo fai perché è troppo lento, allora dovresti farlo perché ti aiuta a scrivere il tuo programma. L'ottimizzazione dovrebbe sempre arrivare dopo. Può anche darsi che rimuovere i thread dal tuo programma lo stia ottimizzando (anche se non è così per la maggior parte dei programmatori).
Neil,

OT: Adoro il tuo avatar. Mi fa sorridere.
Marjan Venema,

@exhuma, sono d'accordo con questa risposta, ma vorrei aggiungere che se hai intenzione di usare i thread per semplicità di codice, va bene, ma fai molta attenzione a capire la sicurezza dei thread e i potenziali gotcha con più thread. Ciò che potrebbe sembrare un semplice pezzo di codice multithread potrebbe facilmente avere condizioni di gara nascoste che potrebbero portare a un assortimento di bug molto difficili da rintracciare.
Ben Lee,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.