Qué recursos capturan los hilos bloqueados

Question

Uno de los propósitos principales de escribir código en el modelo de programación asíncrona (más específicamente - usar devoluciones de llamada en lugar de bloquear el hilo) es minimizar el número de hilos de bloqueo en el sistema.

Para ejecutar subprocesos, este objetivo es obvio, debido a los cambios de contexto y los costos de sincronización.

Pero, ¿qué pasa con los hilos bloqueados? ¿Por qué es tan importante reducir su número?

Por ejemplo, cuando se espera una respuesta de un servidor web, un hilo se bloquea y no ocupa tiempo de CPU y no participa en ningún cambio de contexto.

Así que mi pregunta es: que no sea RAM (¿aproximadamente 1 MB por hilo?) ¿Qué otros recursos ocupan los hilos bloqueados?

Y en qué casos este costo realmente justifica la molestia de escribir código asíncrono (el precio podría ser, por y las variables locales para ser campos de clase).

actualización - adicional razones por las que no se mencione o no dio el peso suficiente para:

1. más hilos de bloqueo significa más sobre los recursos comunales

2. más hilos significa más creación y eliminación de hilos que es costoso

3. El sistema definitivamente puede quedarse sin rosca/RAM y luego dejar de atender a los clientes (en un escenario de servidor web, esto puede de hecho llevar el servicio)

Answer 1

Así que mi pregunta es: aparte de la RAM (¿aproximadamente 1 MB por hilo?) ¿Qué otros recursos ocupan los hilos bloqueados?

Este es uno de los más grandes. Dicho esto, hay una razón por la que ThreadPool en .NET permite tantos hilos por núcleo, en 3.5 the default was 250 worker threads per core in the system. (En .NET 4, depende de la información del sistema, como el tamaño de la dirección virtual, la plataforma, etc.). Ahora no hay un valor predeterminado fijo.) Los subprocesos, especialmente los bloqueados, realmente no son tan caros ...

Sin embargo, diría que, desde el punto de vista de administración de código, vale la pena reducir el número de subprocesos bloqueados. Cada hilo bloqueado es una operación que, en algún momento, debe regresar y desbloquearse. Tener muchos de estos significa que tienes un conjunto bastante complicado de código para administrar. Mantener este número reducido ayudará a mantener la base del código más simple y más fácil de mantener.

Y otra pregunta más subjetivo: ¿En qué casos le costará esto realmente justificar la molestia de escribir un código asíncrono (el precio podría ser, por ejemplo, dividiendo su método coherente agradable a un montón de métodos beginXXX y EndXXX, y moviendo parámetros y variables locales para ser campos de clase).

En este momento, a menudo es un dolor. Depende mucho del escenario. La clase Task<T> en .NET 4 mejora drásticamente esto para muchos escenarios, sin embargo. Al usar el TPL, es mucho menos doloroso que antes usando el APM (BeginXXX/EndXXX) o incluso el EAP.

Es por eso que los diseñadores de idiomas están poniendo tanto esfuerzo en improving this situation in the future. Sus objetivos son hacer que el código asíncrono sea mucho más simple de escribir, para permitir que se use con más frecuencia.

Answer 2

Además de cualquier recurso, el hilo bloqueado puede mantener un bloqueo, el tamaño del grupo de subprocesos también es una consideración. Si ha alcanzado el tamaño máximo del grupo de subprocesos (si recuerdo correctamente para .NET 4 es el recuento máximo de subprocesos es 100 por CPU) simplemente no podrá obtener nada más para ejecutar en el grupo de subprocesos hasta que obtenga al menos un subproceso liberado.

Answer 3

Me gustaría señalar que la cifra de 1MB para la memoria de pila (o 256KB, o lo que sea que esté configurado) es una reserva; mientras que elimina el espacio de direcciones disponible, la memoria real solo se confirma cuando es necesaria.

Por otro lado, tener un número muy grande de hilos está destinado a atascar un poco el programador de tareas, ya que tiene que hacer un seguimiento de ellos (que se han podido ejecutar desde el último tic y así sucesivamente).