Domanda

Come rendi la tua applicazione multithread?Utilizzi funzioni asincrone?oppure apri un nuovo thread?Penso che le funzioni asincrone stiano già generando un thread, quindi se il tuo lavoro sta semplicemente leggendo alcuni file, essere pigro e generare semplicemente il tuo lavoro su un thread non farebbe altro che "sprecare" risorse...Quindi esiste una sorta di progettazione quando si utilizzano funzioni thread o asincrone?

È stato utile?

Soluzione

La generazione di thread sprecherà risorse solo se inizi a generarne tonnellate, uno o due thread extra non influiranno sulle prestazioni della piattaforma, infatti System attualmente ha oltre 70 thread per me e msn ne sta usando 32 (ne ho davvero non ho idea di come un messenger possa utilizzare così tanti thread, specialmente quando è ridotto a icona e non fa davvero nulla...)

Di solito un buon momento per generare un thread è quando qualcosa richiede molto tempo, ma devi continuare a fare qualcos'altro.

ad esempio, supponiamo che un calcolo richiederà 30 secondi.La cosa migliore da fare è generare un nuovo thread per il calcolo, in modo da poter continuare ad aggiornare lo schermo e gestire qualsiasi input dell'utente perché gli utenti lo odieranno se la tua app si blocca fino al termine del calcolo.

D'altra parte, creare thread per fare qualcosa che può essere fatto quasi istantaneamente è quasi inutile, poiché il sovraccarico della creazione (o anche solo del passaggio del lavoro a un thread esistente utilizzando un pool di thread) sarà maggiore rispetto al semplice svolgimento del lavoro nel thread. primo posto.

A volte puoi suddividere la tua app in un paio di parti separate che vengono eseguite nei rispettivi thread.Ad esempio, nei giochi gli aggiornamenti/fisica ecc. possono essere un thread, mentre le immagini grafiche sono un altro, il suono/musica è un terzo e il networking è un altro.Il problema qui è che devi davvero pensare a come queste parti interagiranno, altrimenti potresti avere prestazioni peggiori, bug che si verificano apparentemente "casualmente", o potrebbe addirittura bloccarsi.

Altri suggerimenti

Se stai parlando di .Net, non dimenticare il file DiscussionePool.Il pool di thread è anche ciò che spesso utilizzano le funzioni asincrone.La generazione di troppi thread può effettivamente compromettere le prestazioni.Un pool di thread è progettato per generare thread sufficienti per eseguire il lavoro più velocemente.Quindi usa un pool di thread invece di espandere i tuoi thread, a meno che il pool di thread non soddisfi le tue esigenze.

PS:E tieni d'occhio il Estensioni parallele da Microsoft

Io secondo Il Lanciere del Fuoco risposta: creare i propri thread è un modo eccellente per elaborare attività di grandi dimensioni o gestire un'attività che altrimenti "bloccherebbe" il resto dell'app sincrona, Ma devi avere una chiara comprensione del problema che devi risolvere e sviluppare in un modo che definisca chiaramente il compito di un thread e limiti la portata di ciò che fa.

Per un esempio su cui ho lavorato di recente: un'app console Java viene eseguita periodicamente per acquisire dati essenzialmente selezionando gli URL dello schermo, analizzando il documento con DOM, estraendo i dati e archiviandoli in un database.

Essendo un'applicazione a thread singolo, come ci si aspetterebbe, ha impiegato un'eternità, con una media di circa 1 URL al secondo per una pagina da 50 kb.Non troppo male, ma quando si aumenta la necessità di elaborare migliaia di URL in un batch, non va bene.

La profilazione dell'app ha mostrato che per la maggior parte del tempo il thread attivo era inattivo - era in attesa di operazioni di I/O - apertura di un socket all'URL remoto, apertura di una connessione al database ecc.È questo tipo di situazione che può essere facilmente migliorata con il multithreading.La riscrittura per essere multi-thread e con soli 5 thread invece di uno, anche su una CPU single core, ha dato un aumento del throughput di oltre 20 volte.

In questo esempio, ogni thread "di lavoro" era esplicitamente limitato a ciò che faceva: aprire l'URL remoto, analizzare i dati, archiviarli nel database.Tutta l'elaborazione di "alto livello", ovvero la generazione dell'elenco di URL da analizzare, l'elaborazione di quale successivo, la gestione degli errori, è rimasta sotto il controllo del thread principale.

L'uso dei thread ti fa pensare di più al modo in cui la tua applicazione necessita del threading e, a lungo termine, può rendere più semplice migliorare/controllare le tue prestazioni.
I metodi asincroni sono più veloci da usare ma sono un po' magici - accadono molte cose per renderli possibili - quindi è probabile che ad un certo punto avrai bisogno di qualcosa che non possono darti.Quindi puoi provare a eseguire un codice di threading personalizzato.
Dipende dai tuoi bisogni.

La risposta è, dipende".

Dipende da cosa stai cercando di ottenere.Presumo che tu stia puntando a maggiori prestazioni.

La soluzione più semplice è trovare un altro modo per migliorare le tue prestazioni.Esegui un profiler.Cerca i punti caldi.Riduci gli I/O non necessari.

La soluzione successiva è suddividere il programma in più processi, ognuno dei quali può essere eseguito nel proprio spazio di indirizzi.Questo è più semplice perché non c'è alcuna possibilità che i singoli processi si confondano a vicenda.

La soluzione successiva è utilizzare i thread.A questo punto stai aprendo un grosso vaso di worm, quindi inizia in piccolo e esegui il multithread solo nel percorso critico del codice.

La soluzione successiva consiste nell'utilizzare l'IO asincrono.Generalmente consigliato solo a persone che scrivono server con carichi molto elevati, e anche in questo caso preferirei riutilizzare uno dei framework esistenti che astrae i dettagli, ad es.il framework C++ ICE o un server EJB sotto Java.

Tieni presente che ciascuna di queste soluzioni ha più sottosoluzioni: esistono diversi tipi di thread e diversi tipi di IO asincrono, ciascuno con caratteristiche prestazionali leggermente diverse, ma, ancora una volta, è generalmente meglio lasciare che sia il framework a gestirlo per te.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top