Grupo de subprocesos frente a muchos subprocesos individuales

Question

Estoy en medio de un problema en el que no puedo decidir qué solución tomar.

El problema es un poco único. Digámoslo de esta manera, recibo datos de la red continuamente (de 2 a 4 veces por segundo). Ahora cada dato pertenece a un grupo diferente, digamos. Ahora, llamemos a estos grupos, grupo1, grupo2, etc.

Cada grupo tiene una cola de trabajos dedicada donde los datos de la red se filtran y se agregan a su grupo correspondiente para su procesamiento.

Al principio creé un hilo dedicado por grupo que tomaría los datos de la cola de trabajos, los procesaría y luego pasaría al estado de bloqueo (utilizando la Cola de bloqueo vinculada).

Pero mi superior me sugirió que debería usar grupos de subprocesos porque de esta manera los subprocesos no se bloquearán y otros grupos los podrán usar para procesarlos.

Pero aquí está la cosa, la obtención de datos es lo suficientemente rápida y el tiempo que tarda un hilo en procesarla es suficiente para que el hilo, posiblemente, no entre en modo de bloqueo. Y esto también garantizará que los datos se procesen de forma secuencial (el trabajo 1 se realiza antes del trabajo 2), lo que al juntar, escasas posibilidades, podría no suceder.

Mi senior también está empeñado en el hecho de que la agrupación también nos ahorrará mucha memoria porque los hilos están agrupados (creo que realmente fue por la palabra;)). Si bien no estoy de acuerdo con esto porque, personalmente creo, agrupados o no, cada hilo obtiene su propia memoria de pila. A menos que haya algo en los grupos de hilos que no conozco.

Una última cosa, siempre pensé que la agrupación ayuda donde los trabajos aparecen en un gran número por poco tiempo. Esto tiene sentido porque el enhebrado de subprocesos sería una pérdida de rendimiento debido al tiempo necesario para iniciar un subproceso es mucho más que el tiempo dedicado a hacer el trabajo. Así que la puesta en común ayuda mucho aquí.

Pero en mi caso group1, group2, ..., groupN siempre permanecen con vida. Entonces, si hay datos o no, todavía estarán allí. Entonces, el engendro de hilos no es el problema aquí.

Mi superior no está convencido y quiere que vaya con la solución de agrupamiento porque su huella de memoria es excelente.

Entonces, ¿qué camino tomar?

Gracias.

Answer 1

Buena pregunta. La agrupación de hecho le ahorra tiempo de inicialización, como usted dijo. Pero tiene otro aspecto: gestión de recursos. Y aquí te estoy preguntando: ¿cuántos grupos (hilos dedicados a la lectura) tienes? ¿Crecen dinámicamente durante el período de ejecución de la aplicación?

Por ejemplo, considere una situación donde la respuesta a esta pregunta es sí. Los nuevos tipos de Grupos se agregan dinámicamente. En este caso, es posible que no desee dedicar un hilo a cada uno, ya que técnicamente no hay restricciones sobre la cantidad de grupos que se crearán, creará muchos hilos y el sistema cambiará de contexto en lugar de hacer un trabajo real . Threadpooling to the rescue-thread pool le permite especificar una restricción en el número máximo de hilos que podrían ser posiblemente creados, sin importar la carga. Por lo tanto, la aplicación puede denegar el servicio de ciertas solicitudes, pero las que se procesan se manejan correctamente, sin agotar críticamente los recursos del sistema.

Considerando lo anterior, es muy posible que en su caso, esté muy bien tener un hilo dedicado para cada grupo.

Lo mismo ocurre con la convicción de su superior de que se ahorrará memoria ... De hecho, un hilo ocupa memoria en el montón, pero es realmente tanto, si es una cantidad predefinida, digamos 5. Incluso 10- probablemente esté bien De todos modos, no deberías usar el agrupamiento a menos que estés a priori y absolutamente convencido de que realmente tienes un problema.

La agrupación es una decisión de diseño, no arquitectónica. No se puede agrupar al principio y continuar con las optimizaciones en caso de que encuentre agrupamiento para ser beneficioso. después de ha tenido un problema de rendimiento.

Teniendo en cuenta la serialización de las solicitudes (en la ejecución de la orden), no importa si está utilizando un subproceso o un subproceso dedicado. La ejecución secuencial es una propiedad de la cola junto con una única cadena de caracteres.

Answer 2

Creando un hilo consumirá recursos, incluida la pila predeterminada por hilo (IIR 512Kb, pero configurable). Entonces, la ventaja de agrupar es que incurres en un golpe de recursos limitado. Por supuesto, necesita dimensionar su grupo de acuerdo con el trabajo que debe realizar.

Para su problema en particular, creo que la clave es medir realmente el rendimiento/uso de hilo, etc. en cada escenario. A menos que tenga problemas, tal vez no me preocupe de ninguna manera, aparte de asegurarse de que puede cambiar una implementación por otra sin un gran impacto en su aplicación. Recuerde que optimización prematura es la raíz de todos los males. Note that:

"La optimización prematura" es una frase que se usa para describir una situación donde un programador permite consideraciones de rendimiento afectan el diseño de una pieza de código.Esto puede dar como resultado un diseño que no es tan limpio como podría haber sido o un código que es incorrecto, porque el código es complicado por la optimización y el programador se distrae por la optimización de .