Quali sono le differenze tra i modelli di Threadpool e Pool di oggetti?

Sì, questi pattern sono molto simili, ma sono anche diversi in modi molto cruciali.

Con il pool di oggetti, tutto ciò che fai è estrarre un oggetto per il tuo utilizzo e fai qualunque cosa tu voglia fare con quell'oggetto. Il pool di oggetti viene utilizzato come metodo per prendere in prestito proprietà / controllo di un oggetto per una durata di esecuzione. Un pool di oggetti viene in genere utilizzato quando la creazione di tale oggetto è costosa, scomoda o impossibile poiché gli oggetti sono connessi a una risorsa univoca. Ad esempio, un sistema di integrazione continua può avere più copie del contesto di compilazione (vale a dire la cartella del filesystem o un container), creare un nuovo contesto di build è piuttosto costoso, quindi un pool viene utilizzato per gestire l'accesso al contesto di build. Un altro esempio è la creazione di una nuova connessione TCP / TLS che richiede l'handshake che comporta più round trip verso un server che è probabilmente a metà strada intorno al mondo, quindi un pool di connessioni può essere utilizzato per riutilizzare le connessioni. Un altro esempio può essere l'uso del pool per limitare l'utilizzo di un coprocessore (ad esempio GPU), una macchina fisica può avere accesso solo a un numero limitato di GPU fisiche, quindi è possibile utilizzare un pool perché non è possibile semplicemente creare una nuova GPU dal nulla.

Il pool di thread è un tipo di pool di oggetti e internamente un pool di thread potrebbe contenere un pool di oggetti, tuttavia quando le persone parlano di pool di thread, in genere non stanno parlando del pool di oggetti sottostante, ma piuttosto di thread pool è in realtà solo un particolare tipo di implementazione del pattern Executor. La differenza tra il pool di oggetti tipico e il pool di thread è che con un pool di thread, anziché eseguire il checkout di un oggetto, si invia un'attività che deve essere completata in modo asincrono e in parallelo. Il pool di thread eseguirà quell'attività nel pool di thread di lavoro che attende nella coda dei task del pool.

La differenza tra un pool di thread e un pool di oggetti è uguale alla differenza tra una Toyota Corolla e un veicolo.

Un pool di oggetti è un pool di oggetti. Un pool di thread è un pool di oggetti, ma non qualsiasi tipo di oggetto, solo thread.

Entrambi hanno lo stesso scopo di base: oggetti costosi da creare, costosi da distruggere, numero limitato o qualsiasi combinazione di questi, vengono memorizzati anziché distrutti quando non sono più necessari e riutilizzati invece di creati quando è necessario un "nuovo".

Si noti che nel caso generale, il pool di oggetti è un anti -pattern. Gli oggetti non dovrebbero essere costosi. Se lo sono, allora c'è qualcosa di sbagliato nel tuo ambiente di runtime. In un linguaggio OO, non dovrebbe avere bisogno di non pensare se puoi permetterti di creare o meno un oggetto. Gli oggetti sono la base di OO, se il tuo runtime non può gestire un paio di milioni di oggetti, ottenerne uno migliore.

Allo stesso modo, nella programmazione multi-thread, i thread sono gli elementi costitutivi di base e il tuo runtime non dovrebbe limitarti nel modo in cui li stai usando. Ad esempio, sulla macchina virtuale BEAM / HiPE, è possibile creare 10 milioni di processi (si noti che i processi sono molto più costosi dei thread; in pratica i thread hanno solo un puntatore di istruzioni, uno stack e alcuni thread limitati) archiviazione locale, i processi hanno il loro heap, la loro memoria protetta e su BEAM / HiPE anche i propri garbage collector) su un laptop a 32-bit di 15 anni senza nemmeno una goccia di sudore, quindi non è impossibile fare i thread a buon mercato.

Tuttavia, viviamo nel mondo reale, e ci sono alcuni ambienti di runtime in cui i thread sono così costosi che riutilizzarli è una necessità. Ad esempio, su Linux, un thread pesa 4 KiByte o 8 KiByte rispetto a un processo BEAM / HiPE, che è solo ~ 300 Byte. Ed è qui che entra in gioco il pool di thread.

Creiamo un certo numero di thread (in genere nello stesso ordine in cui abbiamo core CPU per il calcolo più un paio di I / O). E poi creiamo un'astrazione leggera (chiamiamola CodeSnippet ) che è fondamentalmente la stessa cosa di un thread o di un processo, ma leggera, e possiamo creare il maggior numero di quelli che vogliamo. Quando vogliamo eseguire uno di questi frammenti di codice, estraiamo un thread dal nostro pool, lo eseguiamo, prendiamo il risultato, disponiamo lo snippet di codice (ricordate, è leggero, quindi creare e distruggere non è un problema) e inserire il thread di nuovo in piscina. In questo modo, possiamo avere un'astrazione leggera di una cosa simile a un thread mappata ai thread attuali senza dover creare un numero elevato di thread o limitarci a utilizzare solo un numero limitato di oggetti simultanei.

Un pool di thread è un tipo di pool di oggetti, ad eccezione del fatto che i thread coinvolti nel pool contengono una risorsa del sistema operativo (sia temporaneamente che permanentemente).

Ciò significa che potrebbe, in teoria, essere un'implementazione del pooling di thread che non raggruppa oggetti (lingua) e crea invece un nuovo oggetto thread (lingua) con un thread del sistema operativo esistente dal pool di thread. In tale implementazione, dovremmo comunque riconoscere il pooling di thread ma non il pooling di oggetti.

Anche la gestione dell'oggetto in un pool di oggetti e pool di thread può essere diversa, poiché gli oggetti del pool di thread possono essere gestiti in modo altamente controllato e rispetto a specifiche interazioni del sistema operativo, mentre un pool di oggetti può essere gestito in modo più semplice .

Il pool di thread è specificamente inteso allo scopo di eseguire in modo più efficiente l'attività, mentre il modello di progettazione del pool di oggetti è più generale.