Iba a hacer un comentario, pero se hizo demasiado largo.
CodemonkeyKing parece haber llegado a un punto importante, aunque no lo suficiente en mi opinión.
Existen muchos criterios que puede utilizar para describir el código. ¿Será utilizado en una aplicación de larga ejecución o no? Aplicación Winforms o no? ¿Es una aplicación de servidor o cliente? biblioteca o exe independiente? etc. etc.
Me parece que si su código se ejecutará en una aplicación independiente y usted tiene control sobre todo el código circundante, entonces puede rodar su propio grupo de subprocesos, iniciar sus propios hilos y medir y administrar el costo alrededor del inicio del hilo, latencia del hilo y el consumo de recursos. O puede usar el QUWI, pero no matará su aplicación de ninguna manera. Eres libre de elegir.
Por otro lado, si su código está empaquetado como una biblioteca que puede usarse en un servidor -en ASP.NET, o tal vez en una aplicación SQL CLR, o un Servicio WCF- entonces es una muy mala idea crear hilos. Necesita usar QUWI o algún otro mecanismo que explote el grupo de subprocesos integrado (como BackgroundWorker). Si se va a usar en aplicaciones del lado del cliente con otras bibliotecas, una vez más, se requiere QUWI. Imagine que todas las bibliotecas que quieran aprovechar las computadoras multinúcleo hagan sus propios hilos. Habría un caos completo en las aplicaciones que usaban más de unas pocas bibliotecas. Hilos desenfrenados, todos compiten por los mismos recursos. Sin coordinación central de #threads vs # procesadores.
buena higiene exige que una biblioteca, si se va a consumir en las aplicaciones de cliente o de servidor de aplicaciones, utiliza el threadpool común, y eso significa que QUWI.
Lo último que se debe tener en cuenta es esto;
Un subproceso gestionado es un subproceso en segundo plano o un subproceso en primer plano. Los subprocesos de fondo son idénticos a los subprocesos de primer plano con una excepción: un subproceso en segundo plano no mantiene en ejecución el entorno de ejecución administrada. Una vez que todos los subprocesos de primer plano se han detenido en un proceso administrado (donde el archivo .exe es un ensamblado administrado), el sistema detiene todos los subprocesos de fondo y se apaga.
Los subprocesos que pertenecen al grupo de subprocesos administrados (es decir, los subprocesos cuya propiedad IsThreadPoolThread es verdadera) son subprocesos de fondo. Todos los hilos que ingresan al entorno de ejecución administrada desde un código no administrado se marcan como hilos de fondo. Todos los hilos generados al crear e iniciar un nuevo objeto Thread son por defecto hilos de primer plano.
Si usa un hilo para controlar una actividad, como una conexión de socket, establezca su propiedad IsBackground en verdadero para que el hilo no impida que su proceso finalice.
del MSDN site.
Realmente no me beneficié de esa discusión, que parecía ser principalmente un debate sobre el costo de comenzar un hilo. – Cheeso
Pensé que el enlace era genial. No vi nada sobre el costo de iniciar un hilo en la respuesta aceptada, pero varias limitaciones de la lista de temas se enumeran bastante bien allí. – BrainSlugs83