Analogy per i pool di thread

3

Sto lavorando su un'applicazione che genera un nuovo thread per richiesta. A volte il numero di thread attivi sulla macchina in una volta è nelle centinaia alte. Si sospetta che questo stia causando tutti i tipi di problemi. Vorrei sperimentare l'utilizzo del pool di thread invece per vedere se questo migliora il throughput di lavoro. Ma prima, devo convincere i poteri che sono per permettermi il tempo.

Come parte della mia argomentazione, ritengo che una buona analogia che paragona il metodo "lancio x thread" della forza bruta alla tecnica dei pool di thread potrebbe aiutare. C'è un'analogia da manuale per questo?

    
posta Anthony 09.08.2012 - 05:01
fonte

3 risposte

8

Non proprio un'analogia da libro di testo:

Il pool di thread per l'applicazione è come il riciclo per le comunità.

Ogni volta che abbiamo sete possiamo andare avanti e comprare una nuova bottiglia d'acqua fatta di tutte le nuove matrimoni. È facile, relativamente economico per noi e abbastanza redditizio per un produttore. Sfortunatamente non scala:

In modo simile, creare un nuovo thread ogni volta da zero è uno spreco (potenzialmente lento) e non ha una protezione. Troppi fili potrebbero esaurire le risorse di un ambiente di esecuzione, proprio come troppe bottiglie di plastica potrebbero sopraffare e avvelenare un habitat naturale.

    
risposta data 09.08.2012 - 07:42
fonte
4

I thread nei pool di thread sono spesso definiti "thread di lavoro" per validi motivi. Sono come alcuni lavoratori in un'azienda, pronti a lavorare su alcuni "compiti", ognuno dei quali richiede uno spazio di lavoro per lavorare, ognuno dei quali ha la coda di elaborazione da eseguire.

Avviare una discussione solo per eseguire un'attività è come trovare le risorse per assumere qualcuno appositamente per questa attività, facendola eseguire, quindi licenziandola.

Ovviamente, se l'attività è molto lunga, rara e specifica, potrebbero non esserci problemi, ma più spesso questo si verifica, più è costoso.

In questo caso, basta mettere l'attività in cima alla coda dei compiti di un lavoratore può essere sufficiente. Se impiega troppo tempo per iniziare a lavorarci, un altro lavoratore che non avrà più compiti da svolgere può rubare l'incarico dalla sua coda. Se nessun lavoratore è disponibile per qualche tempo, significa che non hai abbastanza lavoratori o non può essere fatto velocemente con le risorse disponibili. In particolare, se hai già la quantità massima di lavoratori che puoi utilizzare senza che tutti camminino a piedi di altri, come in un pool di thread, allora non puoi farci nulla se non avere un posto più grande (hardware migliore) o ridurre il carico di lavoro .

Questa analogia può anche facilmente spiegare il costo di interruzione e comunicazione.

    
risposta data 09.08.2012 - 07:58
fonte
1

Immagina di mangiare un intero pacchetto di biscotti Oreo. L'esperienza sarebbe molto più piacevole se non dovessi mangiare le cialde di cioccolato secco ogni volta che vorrai un delizioso centro cremoso, giusto? Usare pool di thread è come impilare i centri di tutti quei cookie tra una singola coppia di wafer!

Questa analogia sarà molto più convincente se si profila il codice e si mostra quanto tempo impiegano le macchine per avviare e arrestare i thread (mangiare i wafer) rispetto al tempo speso per i centri cremosi (effettivamente gestendo le richieste).

Dai un'occhiata a libdispatch se hai bisogno di un'implementazione.

    
risposta data 09.08.2012 - 08:09
fonte

Leggi altre domande sui tag