Quando non è multi-threading una buona idea?

voti
24

Recentemente stavo lavorando su un'applicazione che messaggi inviati e ricevuti su Ethernet e Seriale. Mi è stato poi incaricato di aggiungere il monitoraggio dei discreti DIO. I THROUGHT,

Non c'è motivo di interrompere il thread principale che è coinvolto nella elaborazione dei messaggi, mi limiterò a creare un altro thread che monitora DIO.

Questa decisione, però, ha dimostrato di essere poveri . A volte il thread principale sarebbe interrotto tra un invio e ricezione di un messaggio di serie. Questa interruzione sconvolgerebbe i tempi e, ahimè, i messaggi si sarebbe perduta (per sempre).

Ho trovato un altro modo per monitorare il DIO senza l'utilizzo di un altro thread e Ethernet e di comunicazione seriale sono stati riportati al loro corretto funzionamento.

L'intero fiasco, però, mi ha fatto pensare. Sono loro eventuali linee guida generali su quando non utilizzare più-thread e / o qualcuno ha più esempi di situazioni in cui l'utilizzo di più-thread non è una buona idea?

** EDIT: sulla base di osservazioni e dopo scowering Internet di informazioni, ho composto un post dal titolo Quando non è multi-threading una buona idea?

È pubblicato 18/09/2008 alle 14:54
fonte dall'utente
In altre lingue...                            


14 risposte

voti
4

In realtà, più threading non è scalabile ed è difficile da mettere a punto, quindi non dovrebbe essere usato in ogni caso se si può evitare. C'è alcuni casi in cui è obbligatoria: quando le prestazioni su un multi questioni CPU, o quando si affronta whith un server che hanno un sacco di clienti che prendono molto tempo per rispondere.

In tutti gli altri casi, è possibile utilizzare alternative come cron jobs coda + o altro.

Risposto il 18/09/2008 a 15:00
fonte dall'utente

voti
1

In ogni priciple non c'è sovraccarico per il chiamante di attendere in una coda.

Risposto il 18/09/2008 a 15:01
fonte dall'utente

voti
0

Sono i processi paralleli? È la prestazione di una preoccupazione reale? Ci sono molteplici 'thread' di esecuzione come su un server web? Non credo che ci sia una risposta finita.

Risposto il 18/09/2008 a 15:01
fonte dall'utente

voti
2

Multi-threading non è una buona idea se avete bisogno di garantire tempi precisi fisica (come nel tuo esempio). Altri svantaggi includono lo scambio di dati intenso tra thread. Direi che il multi-threading è un bene per le attività veramente in parallelo se non si cura molto circa la loro velocità relativa / priorità / temporizzazione.

Risposto il 18/09/2008 a 15:04
fonte dall'utente

voti
14

  1. Su una macchina a singolo processore e un'applicazione desktop, è possibile utilizzare multi-thread in modo da non bloccare l'applicazione, ma per niente altro davvero.
  2. Su un singolo server processore e un'applicazione web based, non c'è bisogno per il multi threading perché il server Web gestisce la maggior parte di esso.
  3. Su una macchina multi-processore e un'applicazione desktop, si suggerisce di utilizzare multi-thread e la programmazione parallela. Fai come le discussioni in quanto vi sono i processori.
  4. Su un server multi-processore e una web app basata, non c'è bisogno di nuovo per il multi thread perché il server Web gestisce.

In totale, se si utilizza più thread per diverso da applicazioni desktop non-congelamento e qualsiasi altra risposta generica, si farà l'applicazione più lento se si dispone di una singola macchina di base a causa delle discussioni interrompendosi a vicenda.

Perché? A causa dei interruttori hardware. Ci vuole tempo per l'hardware per commutare tra i thread in totale. Su una macchina multi-core, andare avanti e utilizza 1 filo per ogni core e voi grandemente vedere una rampa.

Risposto il 18/09/2008 a 15:08
fonte dall'utente

voti
6

Per parafrasare un vecchio preventivo: Un programmatore ha avuto un problema. Ha pensato, "Io so, io uso le discussioni." Ora il programmatore ha due problemi. (Spesso attribuito alla JWZ, ma sembra precedere il suo uso di esso si parla di espressioni regolari.)

Una buona regola è "Non usare le discussioni, a meno che non ci sia un motivo molto valido per utilizzare i thread." Più thread sono in cerca di guai. Prova a trovare un buon modo per risolvere il problema senza l'utilizzo di più thread, e ricadere a utilizzare le discussioni se evitando è come molti problemi come lo sforzo supplementare per utilizzare i thread. Inoltre, passare ad filetti multipli se si sta eseguendo su una macchina multi-core / multi-CPU, e test delle prestazioni della versione thread singolo indica che serve le prestazioni dei nuclei supplementari.

Risposto il 18/09/2008 a 15:10
fonte dall'utente

voti
2

Una recente applicazione che ho scritto che doveva usare il multithreading (anche se il numero non è illimitata di thread) è stata quella in cui ho dovuto comunicare in diverse direzioni più di due protocolli, oltre il monitoraggio di una terza risorsa per le modifiche. Entrambe le biblioteche protocollo richiesto un thread per eseguire il rispettivo ciclo di eventi, e quando queste sono state valutate, è stato facile creare un terzo ciclo per il monitoraggio delle risorse. In aggiunta ai requisiti ciclo di eventi, i messaggi che passano attraverso i fili avevano severi requisiti di temporizzazione, e un ciclo non potevano essere rischiato bloccando l'altro, qualcosa che è stato ulteriormente alleviato utilizzando una CPU multicore (SPARC).

Ci sono state ulteriori discussioni su se ogni elaborazione del messaggio deve essere considerato un lavoro che è stato dato a un filo da un pool di thread, ma alla fine che era un'estensione che non valeva il lavoro.

All-in-tutto, le discussioni dovrebbero se possibile essere considerato solo quando è possibile suddividere il lavoro in posti di lavoro ben definiti (o una serie di posti di lavoro) in modo tale che la semantica sono relativamente facili da documentare e implementare, e si può mettere un limite superiore alla numero di thread utilizzati e che hanno bisogno di interagire. I sistemi in cui questo è meglio applicare sono quasi un messaggio di sistemi di passaggio.

Risposto il 18/09/2008 a 15:10
fonte dall'utente

voti
1

Direi che il multi-threading è generalmente utilizzato per:

  1. Consentire l'elaborazione dei dati in background mentre una GUI rimane reattivo
  2. Split molto grande analisi dei dati su più unità di elaborazione in modo che è possibile ottenere i risultati più rapidamente.
  3. Quando si sta ricevendo i dati da alcuni componenti hardware e hanno bisogno di qualcosa da aggiungere continuamente ad un buffer, mentre qualche altro elemento decide cosa fare con esso (scrivere su disco, la visualizzazione su una GUI, ecc).

Quindi, se non siete risolvere uno di questi problemi, è improbabile che le discussioni che aggiungono renderanno la vostra vita più facile. In realtà sarà quasi certamente rendere più difficile perché, come altri hanno detto; debug di applicazioni mutithreaded è considerevolmente più lavoro di una singola soluzione filettato.

Sicurezza potrebbe essere un motivo per evitare l'uso di più thread (su più processi). Vedere Google Chrome per un esempio di funzioni di sicurezza multi-processo.

Risposto il 18/09/2008 a 15:23
fonte dall'utente

voti
3

Si potrebbe voler dare un'occhiata al Kegel di Dan " Il problema C10K " pagina web sulla gestione di dati multipli fonti / lavandini.

Fondamentalmente è meglio usare le discussioni minime, che in zoccoli può essere fatto nella maggior parte dei sistemi operativi w / qualche sistema evento (o asincrono in Windows utilizzando IOCP).

Quando si esegue in caso in cui il sistema operativo e / o librerie non offrono un modo per eseguire la comunicazione in modo non-blocking, è meglio usare un pool di thread per gestirli durante la sua relazione di nuovo allo stesso ciclo di eventi.

Schema Esempio di aspetto:

Per CPU [*] EVENTLOOP   ------ Handles nonblocking I/O using OS/library utilities
                       |                        \___  Threadpool for various blocking events
                       Threadpool for handling the I/O messages that would take long
Risposto il 18/09/2008 a 15:40
fonte dall'utente

voti
1

Un altro paio di possibili motivi per utilizzare le discussioni:

  1. La vostra piattaforma manca I asincrono / O operazioni, ad esempio, Windows ME (Nessun porte di completamento o di I / O sovrapposto, un dolore quando il porting delle applicazioni di XP che li utilizzano.) Java 1.3 e versioni precedenti.
  2. Una funzione di libreria di terze parti che possono appendere, ad esempio, se un server remoto è giù, e la biblioteca fornisce alcun modo per annullare l'operazione e non è possibile modificarlo.

Mantenere una GUI reattivo durante l'elaborazione intensiva non richiede sempre thread aggiuntivi. Una singola funzione di callback è generalmente sufficiente.

Se nessuna delle precedenti si applicano e voglio ancora il parallelismo per qualche motivo, preferisco lanciare un processo indipendente, se possibile.

Risposto il 18/09/2008 a 16:52
fonte dall'utente

voti
6

Multi-threading è una cattiva idea se:

  • Diverse le discussioni accedere e aggiornare la stessa risorsa (impostare una variabile, scrivere in un file), e non si capisce la sicurezza dei thread .

  • Diverse le discussioni interagiscono tra di loro e non si capisce mutex e simili strumenti di gestione thread.

  • Il programma utilizza le variabili statiche (discussioni in genere li condividono per impostazione predefinita).

  • Non hai il debug problemi di concorrenza.

Risposto il 10/11/2008 a 04:48
fonte dall'utente

voti
0

Una fonte comune di problemi di threading è soliti approcci utilizzati per sincronizzare i dati. Avendo thread condividono stato e quindi implementare bloccaggio in tutti i luoghi appropriati è una delle principali fonti di complessità sia per la progettazione e debugging. Ottenere il diritto di blocco per bilanciare la stabilità, le prestazioni e la scalabilità è sempre un problema difficile da risolvere. Anche gli esperti più esperti sbagliano spesso. Tecniche alternative per affrontare filettatura possono alleviare gran parte di questa complessità. Il Clojure linguaggio di programmazione implementa diverse tecniche interessanti per affrontare la concorrenza.

Risposto il 08/06/2009 a 16:56
fonte dall'utente

voti
2

Il multithreading è male, tranne nel solo caso in cui essa è buona. Questo caso è

  1. Il lavoro è CPU Bound, o parti di esso è CPU Bound
  2. Il lavoro è parallelizzabili.

Se una o entrambe queste condizioni sono mancanti, il multithreading non sta per essere una strategia vincente.

Se il lavoro non è tenuto CPU, allora non siete in attesa su thread per finire il lavoro, ma per qualche evento esterno, come l'attività di rete, per il processo di completare il suo lavoro. Utilizzando thread, v'è il costo aggiuntivo di cambi di contesto tra thread, il costo di sincronizzazione (mutex, ecc), e l'irregolarità del filo prelazione. L'alternativa di uso più comune è asincrona IO, in cui un unico filo ascolta più porte IO, e agisce su qualunque sembra essere pronto ora, una alla volta. Se per caso questi canali lenti tutti capita di diventare pronto allo stesso tempo, potrebbe sembrare come potrete godere di un rallentamento, ma in pratica questo è raramente vero. Il costo di trattamento ogni porta è singolarmente spesso paragonabile o superiore al costo di sincronizzare stato su più thread come ciascun canale viene svuotato.

Molti compiti possono essere vincolati calcolo, ma ancora non pratico utilizzare un approccio multithread perché il processo necessario sincronizzare sul l'intero stato. Tale programma non può beneficiare di multithreading perché nessun lavoro può essere eseguita contemporaneamente. Fortunatamente, la maggior parte dei programmi che richiedono enormi quantità di CPU possono essere parallelizzati ad un certo livello.

Risposto il 08/06/2009 a 17:15
fonte dall'utente

voti
1

Multi-threading è scalabile, e permetterà l'interfaccia utente di mantenere la sua responsivness, mentre facendo le cose molto complicate in background. Non capisco dove altre risposte stanno acquisendo le loro informazioni sul multi-threading.

Quando non dovrebbe multi-thread è una domanda fuorvianti al vostro problema. Il tuo problema è questo: perché ha multi-threading mia domanda cause seriali / comunicazioni Ethernet a fallire?

La risposta a questa domanda dipenderà attuazione, che dovrebbe essere discusso in un'altra domanda. So per certo che si può avere sia ethernet e le comunicazioni seriali che accadono in un'applicazione multi-threaded, allo stesso tempo come numerose altre attività senza causare alcuna perdita di dati.

L'unica ragione per non utilizzare il multi-threading è:

  1. C'è un altro compito, e senza interfaccia utente con cui l'attività verrà interferire.

Le ragioni per usare mutli-threading sono:

  1. Offre una risposta superiore per l'utente
  2. Esegue più attività contemporaneamente per ridurre il tempo complessivo di esecuzione
  3. Utilizza più delle CPU multi-core attuali, e multi-multi-core del futuro.

Ci sono tre metodi di base della programmazione multi-threaded che rendono filo di sicurezza implementato con facilità - avete solo bisogno di utilizzare uno per il successo:

  1. Far passare i tipi di dati di sicurezza passati tra i thread.
  2. Infilare metodi sicuri nell'oggetto filettato di modificare i dati passati tra.
  3. capacità PostMessage per comunicare tra i thread.
Risposto il 08/06/2009 a 17:17
fonte dall'utente

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more