Ha senso avere un limite di thread specificato dall'utente?

Non è generalmente ragionevole limitare il numero di thread, se questi thread vengono utilizzati solo per la concorrenza. Cioè a parte l'uso extra di risorse, i thread di generazione sono perfetti per gestire le operazioni di blocco, aumentare la reattività, .... Un buon esempio è un web crawler che potrebbe voler scaricare più piccole risorse e utilizza più thread per compensare la latenza delle richieste. Tuttavia, l'utilizzo di approcci esplicitamente asincroni come IO asincrono o loop di eventi avrà gli stessi vantaggi e, se possibile, dovrebbe essere preferito.

Se la tua applicazione usa il parallelismo per velocizzare i calcoli che intensificano la CPU, limitare il numero di thread è molto utile. Non vedrete alcun vantaggio sulla generazione di spawn come molti thread come processori sono disponibili. Tuttavia, il tuo programma non è l'unico in esecuzione, e altri programmi a uso intensivo della CPU potrebbero essere eseguiti in parallelo.

Potresti essere molto intelligente e adattare il numero di thread di lavoro al carico corrente del sistema (il che porterebbe a prestazioni imprevedibili del tuo programma). Oppure puoi consentire all'utente di selezionare il numero di thread, che è più sicuro. In particolare, si vorrebbe almeno un'opzione per utilizzare solo un singolo thread di lavoro, il che rende molto più facile il debug. In tal caso, fai ciò che make fa: un singolo thread è un buon valore predefinito, ma alcuni utenti hanno bisogno della piena potenza di make -j$(nproc) .

I thread IMO possono essere suddivisi in tre categorie principali.

Thread a lunga esecuzione che monitorano una cosa per thread. Mettendo un limite su questi limiti il numero di cose che puoi monitorare, che probabilmente non è quello che vuoi fare. Se metti un limite, dovrebbe essere molto alto e soprattutto un controllo di integrità.

Thread che trascorrono la maggior parte del loro tempo al calcolo. Generalmente vuoi un numero simile di questi nei core della CPU.

Thread che funzionano sull'elaborazione delle richieste con una richiesta per thread alla volta, ma dopo che la richiesta è stata completata il thread è distrutto o attende un'altra richiesta. L'elaborazione di una richiesta comporta un utilizzo della CPU ma anche molta attesa per disco / rete / ecc. Qui hai un atto di bilanciamento. Troppi thread significano thrashing delle risorse, troppo pochi significano che la velocità di elaborazione delle richieste è limitata dalla latenza della rete e può significare che le richieste che possono essere servite dalla cache del disco vengono accodate dietro richieste che richiedono di colpire i piatti.