API del grupo de hilos de Win32 — Concurrencia sin crear hilos, con CreateThreadpoolWork

«Un CreateThread por cliente.» «Uno para el temporizador.» «Uno para esperar un evento.» En el código nativo de Windows se tiende a multiplicar hilos para trabajos pequeños. Cada hilo consume una pila y un objeto del kernel, y crearlos y destruirlos también tiene un coste.

Lo que absorbe ese desajuste es la API del grupo de hilos de Win32, estándar del sistema operativo. La aplicación entrega el procesamiento que quiere ejecutar como devolución de llamada y deja la gestión de los hilos trabajadores al sistema operativo. «No crear hilos» no significa que los hilos dejen de ser necesarios. Significa que la aplicación no crea y destruye uno por cada trabajo.¹

Este artículo se dirige a quienes escriben aplicaciones, servicios y DLL de Windows en C/C++, y sigue el orden elección de la herramienta → selección del objeto → implementación de work → precauciones de las devoluciones de llamada y del apagado. El tema es la familia CreateThreadpoolWork rediseñada en Windows Vista. El código es un extracto que muestra el esqueleto del uso; las partes propias de la aplicación, como la cola, se omiten.

1. Primero la conclusión

Si procesa un gran número de trabajos de corta duración, gestione trabajos en lugar de hilos. Quién diseña cuándo se detiene un trabajo y cuándo puede liberarse, sin embargo, es la aplicación.

La decisión gira en torno a tres ejes.

• Elegir la herramienta. Si bastan las herramientas de C++ estándar o de .NET, úselas. El turno de esta API llega cuando quiere unificar temporizadores, esperas y finalización de E/S en Win32, o dividir grupos.
• Entregar el trabajo en unidades de trabajos. Use work, timer, wait e io de la API nueva, y deje en un hilo dedicado los trabajos que necesitan estado propio del hilo, como una prioridad de hilo o una STA de COM.
• Construir el apagado como parte del conjunto. La forma básica es «dejar de enviar → esperar la finalización → cerrar». Dentro de una devolución de llamada, no bloquee durante mucho tiempo, no espere de forma síncrona trabajo del mismo grupo y restablezca el estado del hilo.

Si quiere poner algo en marcha primero, empiece por el ejemplo de work del capítulo 4 y luego compruebe la disciplina de las devoluciones de llamada en el capítulo 5. El apagado agrupado de varios objetos se trata en el capítulo 6, y la descarga de una DLL en el capítulo 7.

2. Elección — grupo, hilo dedicado y biblioteca estándar

2.1 Un grupo encaja con trabajo corto, numeroso y centrado en la espera

Un grupo de hilos es un conjunto de hilos trabajadores gestionados por el sistema operativo. Los trabajadores ejecutan las devoluciones de llamada una tras otra, y el sistema operativo ajusta su número según la carga. Al entregar el trabajo que hacía creando y desmontando hilos propios, reduce tanto el código de gestión como el coste de creación y destrucción.¹

La documentación oficial enumera como candidatas las aplicaciones que emiten en paralelo un gran número de elementos de trabajo pequeños, las que crean y destruyen con frecuencia hilos de corta duración, las que procesan en paralelo trabajo independiente en segundo plano, y las que tienen hilos dedicados a esperar objetos del kernel o eventos. La búsqueda, las E/S de red y consolidar los hilos que solo esperan son típicos.¹

Por otro lado, el trabajo que necesita un cambio de prioridad de hilo, una STA de COM, o que sigue ejecutándose durante toda la vida del proceso, se queda en un hilo dedicado. El criterio es si basta con que el procesamiento se ejecute, o si el propio hilo necesita una «personalidad».

flowchart TB
    accTitle: Elección entre hilo dedicado y grupo
    accDescr: Comprobar primero si el hilo necesita una personalidad como una prioridad o una STA, y si se ejecuta durante mucho tiempo; solo el trabajo corto, numeroso o de espera que no encaja en ninguno de los dos va al grupo de hilos
    q1{"¿Necesita personalidad, p. ej. prioridad o STA?"} -->|"Sí"| ded["Mantener en un hilo dedicado"]
    q1 -->|"No"| q2{"¿Se ejecuta durante mucho tiempo?"}
    q2 -->|"Sí"| ded
    q2 -->|"No"| pool["Poner en el grupo de hilos"]
    pool -.-> ex["Trabajo corto, esperas, temporizadores, finalizaciones de E/S"]

Figura 1: Al grupo solo pertenece el trabajo que «no necesita personalidad y termina pronto». Todo lo demás se queda en un hilo dedicado como hasta ahora.

2.2 Preguntar primero si basta C++ estándar o .NET

Si la granularidad la cubren std::async o std::thread de C++, la biblioteca estándar es la primera candidata. Es portable, y el comportamiento de std::async y future se puede tratar con base en el estándar.²

Las razones para usar de forma directa el grupo de hilos de Win32 son requisitos como querer un mecanismo unificado de devolución de llamada que incluya timer, wait e io; querer grupos o números de hilos distintos por tipo de trabajo; no querer mantener hilos propios dentro de una DLL o un componente COM. Separe la pregunta de si simplemente quiere paralelismo de la de si necesita control específico de Windows.

flowchart TB
    accTitle: Decidir con las herramientas de qué capa escribir
    accDescr: Si async o thread de C++ estándar bastan, usarlos; usar de forma directa el grupo de hilos de Win32 cuando hace falta unificar temporizadores, esperas y finalización de E/S, dividir grupos o controlar el número de hilos, o evitar hilos propios dentro de una DLL o un componente COM
    q1{"¿Bastan las herramientas de C++ estándar?"} -->|"Sí"| std["std::async / std::thread"]
    q1 -->|"No"| q2{"¿Qué se necesita?"}
    q2 -->|"Unificar timer, wait e io"| tp["Grupo de hilos de Win32"]
    q2 -->|"Dividir grupos / controlar números"| tp
    q2 -->|"Evitar hilos propios en una DLL"| tp

Figura 2: En caso de duda, empiece por la biblioteca estándar; el turno de esta API llega cuando aparece un requisito que ella no puede expresar.

En .NET, ThreadPool y Task desempeñan el mismo papel, y la finalización de E/S está ligada a IOCP. Para una explicación detallada de la relación, consulte el artículo sobre IOCP y el grupo de hilos de .NET. No hace falta bajar a la API de Win32 donde bastan las herramientas de la capa de encima.

2.3 En código nuevo, use la API nueva a partir de Vista

Hay dos generaciones de API del grupo de hilos de Win32: la API antigua que continúa desde Windows 2000, como QueueUserWorkItem y RegisterWaitForSingleObject, y la familia CreateThreadpoolWork rediseñada por completo en Windows Vista.

La API nueva unificó los tipos de hilo trabajador y aportó una sola cola de temporizador, hilos persistentes dedicados, varios grupos independientes en un proceso y grupos de limpieza. La documentación oficial cita también como ventajas la sencillez, la fiabilidad, el rendimiento y la flexibilidad.¹³

La API antigua tiene además una restricción estructural: no hay forma de cancelar un trabajo una vez encolado. Use la API nueva en código nuevo y, al revisar código existente, parta de la correspondencia siguiente.³

flowchart TB
    accTitle: Correspondencia entre la API antigua del grupo de hilos y la API nueva
    accDescr: QueueUserWorkItem de la API antigua se sustituye por el objeto work de la API nueva, las colas de temporizador por timer, las esperas registradas por wait y BindIoCompletionCallback por io
    o1["QueueUserWorkItem"] --> n1["work"]
    o2["Colas de temporizador"] --> n2["timer"]
    o5["Esperas registradas"] --> n3["wait"]
    o4["BindIoCompletionCallback"] --> n4["io"]

Figura 3: El destino de migración desde la API antigua está fijado uno a uno. Un inventario del código existente puede empezar por esta correspondencia.

3. Funcionamiento — cuatro objetos con distintas condiciones de disparo

3.1 Elegir según qué debe disparar la devolución de llamada

En el centro de la API nueva están los cuatro tipos siguientes. Elija no solo por «qué procesar», sino por qué debe disparar la devolución de llamada.⁴

Las condiciones de disparo difieren, pero quienes ejecutan son los trabajadores del mismo grupo. En lugar de escribir el procesamiento periódico, la reacción a eventos y el tratamiento de finalización de E/S cada uno en su hilo dedicado, puede alinearlos en un mecanismo común de devolución de llamada.

flowchart TB
    accTitle: Separar las condiciones de disparo de la ejecución de las devoluciones de llamada
    accDescr: Los trabajadores del grupo ejecutan las devoluciones de llamada que objetos con condiciones de disparo han dejado listas, y un trabajador que ha terminado se usa también para la siguiente devolución de llamada, de modo que la aplicación no crea un hilo por trabajo
    app["La aplicación indica el trabajo y su condición de disparo"] --> obj["El objeto espera la condición"]
    obj --> ready["La devolución de llamada queda lista para ejecutarse"]
    ready --> workers["Los trabajadores del grupo la ejecutan"]
    workers --> done["Terminar y devolver el trabajador"]
    done --> next["Reutilizado también para la siguiente devolución de llamada"]

Figura 4: Separar el mecanismo que espera el disparo de los trabajadores que ejecutan el procesamiento reduce la gestión de hilos por trabajo.

3.2 También se pueden sustituir los «hilos que solo duermen y esperan»

El beneficio del grupo no se limita al trabajo que usa la CPU. Los temporizadores se consolidan en una sola cola de temporizador, y la espera de varios identificadores en un número reducido de hilos de espera.¹

Por ejemplo, si tiene cinco hilos que solo duermen para «ejecutarse cuando el evento se señaliza», puede pensar en sustituirlos por cinco objetos wait. En lugar de mantener un hilo que duerme por su cuenta para cada uno, ejecuta el procesamiento al señalizarse como devolución de llamada.

flowchart TB
    accTitle: Sustituir hilos que solo esperan por objetos wait
    accDescr: Los hilos que solo esperan, uno por evento, se consolidan en los hilos de espera del grupo al sustituirlos por objetos wait, y la devolución de llamada se ejecuta solo al señalizarse
    old2["5 hilos que solo esperan, durmiendo por separado"] -.-> waste["Consume 5 pilas y 5 hilos"]
    new2["5 objetos wait"] --> agg["Consolidados en los hilos de espera del grupo"]
    agg --> cb2["Devolución de llamada solo al señalizarse"]

Figura 5: Los «hilos que solo duermen y esperan» se pueden eliminar convirtiéndolos en objetos wait. Es el primer paso evidente de una migración al grupo.

4. Bases de la implementación — crear un work, enviarlo y apagar con seguridad

4.1 Primero, un recorrido de la creación al apagado

Recorra el uso una vez con el objeto más básico, work. CreateThreadpoolWork vincula la devolución de llamada a un context, y SubmitThreadpoolWork solicita la ejecución. Si el tercer argumento es NULL, se usa el grupo predeterminado del proceso. Muchos usos bastan con este grupo predeterminado.⁵⁶

Lo siguiente es un extracto que muestra el procedimiento, no un programa completo que compile tal cual. WORK_QUEUE, ITEM, Enqueue, Dequeue y ProcessItem representan el procesamiento del lado de la aplicación. Implemente por separado la exclusión mutua de la cola, detener el lado que envía y el tratamiento de fallos, y si falla la creación del work, no continúe con el envío, la espera y la liberación posteriores.

VOID CALLBACK WorkCallback(PTP_CALLBACK_INSTANCE instance,
                           PVOID context, PTP_WORK work)
{
    // El context se fija en la creación. Los datos de cada elemento se pasan por una cola sincronizada
    WORK_QUEUE* queue = (WORK_QUEUE*)context;
    ITEM* item = Dequeue(queue);        // Extraer un elemento con exclusión mutua
    ProcessItem(item);
}

// 1) Crear (vincular la devolución de llamada al contexto compartido, es decir, la cola)
PTP_WORK work = CreateThreadpoolWork(WorkCallback, &queue, NULL);
if (!work) { /* tratamiento del fallo con GetLastError */ }

// 2) Enviar una vez por cada elemento encolado (hacer coincidir el número de elementos y de envíos)
Enqueue(&queue, item);
SubmitThreadpoolWork(work);

// 3) Detener el lado que envía y luego esperar la finalización (TRUE intenta también cancelar lo que aún no ha empezado)
WaitForThreadpoolWorkCallbacks(work, FALSE);

// 4) Cerrar
CloseThreadpoolWork(work);

flowchart TB
    accTitle: Ciclo de vida de un objeto work
    accDescr: Crear con CreateThreadpoolWork; enviar con SubmitThreadpoolWork ejecuta las devoluciones de llamada en paralelo. En el apagado, detener primero los envíos nuevos, esperar la finalización de todas las devoluciones de llamada con WaitForThreadpoolWorkCallbacks y luego cerrar con CloseThreadpoolWork
    c["Crear con CreateThreadpoolWork"] --> s["Enviar con SubmitThreadpoolWork (repetible)"]
    s --> run["Las devoluciones de llamada se ejecutan en paralelo"]
    run --> stop3["Detener los envíos nuevos"]
    stop3 --> w["Esperar la finalización con WaitForThreadpoolWorkCallbacks"]
    w --> cl["Cerrar con CloseThreadpoolWork"]

Figura 6: El orden de apagado es «dejar de enviar → esperar la finalización → cerrar». Si se salta algún paso, hay acceso después de liberar o una condición de carrera.

4.2 Un work se puede reutilizar, pero el context no cambia en cada envío

El mismo objeto work se puede enviar varias veces, incluso antes de que termine la devolución de llamada anterior. Cada envío ejecuta la devolución de llamada, y varias instancias se ejecutan en paralelo. El número de hilos que se usan de hecho puede ajustarlo el grupo por eficiencia.⁷

Lo que hay que distinguir aquí es el work y los datos de cada elemento de trabajo. El context que se pasa a la devolución de llamada se fija en la creación. Para procesar N elementos de datos distintos con un work, haga de una cola sincronizada el context, como en el ejemplo anterior. Envíe una vez por cada elemento encolado y haga que la devolución de llamada tome un elemento de la cola. Un diseño que crea un objeto work por elemento también es válido.⁵

flowchart TB
    accTitle: Recibir los datos de cada elemento a través de un context fijo
    accDescr: El context se fija a una cola compartida al crear el work; el lado que envía envía una vez por cada elemento encolado, y cada devolución de llamada que se ejecuta en paralelo toma de la cola un elemento cada vez con exclusión mutua
    create["Fijar el context al crear el work"] -.-> queue["Cola compartida con exclusión mutua"]
    item["Encolar un elemento"] --> queue
    item --> submit["Enviar una vez por elemento"]
    submit --> callbacks["Las devoluciones de llamada se ejecutan en paralelo"]
    callbacks --> dequeue["Extraer un elemento cada una"]
    queue --> dequeue
    dequeue --> process["Procesar el elemento extraído"]

Figura 7: Lo que queda fijo es el context que apunta a la cola; los datos de cada elemento se pasan por la cola sincronizada.

4.3 En el apagado, deje de enviar antes de esperar

El orden de apagado seguro es «detener los envíos nuevos → esperar la finalización con WaitForThreadpoolWorkCallbacks → cerrar con CloseThreadpoolWork». La memoria a la que se refiere la devolución de llamada tampoco debe liberarse antes de confirmar la finalización. Si libera el destino de la referencia mientras queda procesamiento en ejecución o pendiente, se produce un acceso después de liberar.⁶

Pensar «llamé a la espera de finalización, así que es seguro» no basta. Si otro hilo todavía puede llamar a SubmitThreadpoolWork, un envío posterior a la espera entra en carrera con Close. Para que la espera sea un hito del apagado, detener antes el lado que envía es un requisito previo.

Si el segundo argumento de WaitForThreadpoolWorkCallbacks es FALSE, espera la finalización; si es TRUE, también solicita la cancelación de las devoluciones de llamada que aún no han empezado. Eso no significa que se pueda abandonar el procesamiento que ya está en ejecución. Cómo apagar varios objetos juntos se trata en el capítulo 6.

5. Disciplina de las devoluciones de llamada — no monopolizar ni contaminar un hilo prestado

5.1 Declare el trabajo largo y compruebe también el valor de retorno

El grupo ajusta su número de hilos asumiendo que las devoluciones de llamada regresan pronto. Si continúa un procesamiento largo o una espera larga sin indicarlo, se retrasa la ejecución de otras devoluciones de llamada. Cuando el trabajo puede tardar, indíqueselo al grupo con CallbackMayRunLong o muévalo a un hilo dedicado.⁸

Sin embargo, llamar a CallbackMayRunLong no basta. La función devuelve FALSE cuando no puede poner un trabajador a disposición de otras devoluciones de llamada. En lugar de ignorar el valor de retorno y seguir bloqueando, en ese caso incline a no atascar el grupo: dividir el procesamiento, moverlo a un hilo dedicado, etc.⁸

flowchart TB
    accTitle: Decidir cómo tratar una devolución de llamada de larga duración
    accDescr: El trabajo que necesita un procesamiento largo o una espera larga se mueve a un hilo dedicado o se anuncia al grupo con CallbackMayRunLong; si vuelve FALSE porque no se pudo disponer de otro trabajador, se evita bloquear dividiendo o moviendo a un hilo dedicado
    long["Hace falta un procesamiento o una espera largos"] --> choice{"Dónde ejecutarlo"}
    choice -->|"Dedicarlo"| dedicated["Mover a un hilo dedicado"]
    choice -->|"En el grupo"| notify["Notificar con CallbackMayRunLong"]
    notify --> result{"¿Se obtuvo otro trabajador?"}
    result -->|"TRUE"| run["Ejecutar el procesamiento largo"]
    result -->|"FALSE"| split["Dividirlo o moverlo a uno dedicado"]

Figura 8: Anunciar un procesamiento largo es un conjunto que incluye comprobar el valor de retorno y decidir la acción siguiente.

5.2 No espere de forma síncrona, desde un trabajador, trabajo del mismo grupo

Un diseño en el que la devolución de llamada A envía el trabajo B al mismo grupo y espera su finalización con WaitForThreadpoolWorkCallbacks o similar requiere cuidado. Cuando todos los trabajadores están «esperando el trabajo de otro trabajador», no queda ningún trabajador libre para ejecutar B, y se produce un interbloqueo por hambruna del grupo.

El remedio no es reservar un trabajador para esperar, sino pasar a una forma de continuación en la que la devolución de llamada de finalización de B envía el trabajo siguiente. No escriba las dependencias como esperas que ocupan un trabajador.

flowchart TB
    accTitle: Estructura de un interbloqueo por hambruna del grupo
    accDescr: Si todos los hilos trabajadores esperan de forma síncrona la finalización de otro trabajo enviado al mismo grupo, no existe un trabajador libre que pueda ejecutarlo, y todos esperan para siempre en un interbloqueo
    w1["Trabajador 1: esperando a que termine el trabajo X"] --> q["Trabajos X e Y esperando a ejecutarse"]
    w2["Trabajador 2: esperando a que termine el trabajo Y"] --> q
    q -.-> none["No hay trabajador libre que los ejecute"]
    none -.-> dead["Todos esperan para siempre (interbloqueo por hambruna)"]

Figura 9: Si un trabajador espera de forma síncrona a un trabajador, no queda nadie que ejecute el trabajo esperado.

5.3 Restablezca el estado del hilo antes de volver

Un hilo trabajador se usa también para la siguiente devolución de llamada, sin relación. Dejar la prioridad cambiada, dejar estado de inicialización COM, dejar un valor en TLS u olvidar liberar un bloqueo se arrastra al trabajo siguiente. No debe asumir que la función que envía al grupo, ni el procesamiento que llama, se ejecuta en un hilo dedicado.⁹

También hay API que ligan la limpieza al final de la devolución de llamada. Por ejemplo, LeaveCriticalSectionWhenCallbackReturns pide al grupo que libere la sección crítica después de que la devolución de llamada regrese.⁴

flowchart TB
    accTitle: No arrastrar el estado del hilo a la siguiente devolución de llamada
    accDescr: Como otra devolución de llamada reutiliza el mismo trabajador, volver dejando estado de prioridad, COM, TLS o bloqueo contamina el trabajo siguiente; limpiar y restablecer el estado evita ese arrastre
    first["La devolución de llamada A toma prestado un trabajador"] --> cleanup{"¿Se limpió antes de volver?"}
    cleanup -->|"No"| dirty["Reutilizado con el estado dejado"]
    dirty --> impact["Afecta a B, sin relación"]
    cleanup -->|"Sí"| clean["Trabajador devuelto en su estado original"]
    clean --> next["La siguiente devolución de llamada B lo usa"]

Figura 10: El hilo está prestado, así que la responsabilidad no es solo el resultado del procesamiento, sino el estado del hilo al devolverlo.

5.4 No deje que las excepciones no controladas se escapen del trabajador

Una excepción no controlada en un hilo trabajador puede arrastrar todo el proceso. Igual que con la función de hilo de un hilo dedicado, aplique la política de capturar las excepciones en la entrada de la devolución de llamada y registrarlas. Dejar la ejecución al grupo no elimina la necesidad de tratar los fallos ocurridos dentro del trabajo.

6. Separar la configuración — grupos personalizados y grupos de limpieza

6.1 Use un grupo personalizado para aislar tipos de trabajo

Cuando el grupo predeterminado ya no basta, puede crear un grupo independiente con CreateThreadpool. SetThreadpoolThreadMaximum y SetThreadpoolThreadMinimum fijan el tope y el suelo del número de hilos trabajadores.¹⁰

El propósito típico es el aislamiento. Para que «un procesamiento por lotes que puede ser lento» no agote los trabajadores de «un trabajo que debe responder de inmediato», divide los grupos y da a cada uno un presupuesto de hilos. No se trata simplemente de añadir hilos; se trata de separar qué trabajo usa qué trabajadores.

6.2 Vincule el destino de ejecución y la limpieza con un entorno de devolución de llamada

Lo que indica en qué grupo ejecutarse es TP_CALLBACK_ENVIRON. Inicializa este entorno de devolución de llamada, indica el grupo con SetThreadpoolCallbackPool y lo pasa a CreateThreadpoolWork y similares. El tercer argumento, que era NULL en el ejemplo del capítulo 4, es el lugar del entorno.⁵

A través del mismo entorno también se puede adjuntar un grupo de limpieza. El grupo personalizado es el destino de ejecución; el grupo de limpieza es la unidad de limpieza. Ver estos dos papeles por separado facilita seguir la configuración.

flowchart TB
    accTitle: Vincular la configuración mediante un entorno de devolución de llamada
    accDescr: El entorno de devolución de llamada apunta a un grupo personalizado y a un grupo de limpieza; los objetos work y timer creados con ese entorno se ejecutan en ese grupo, y la operación masiva del grupo de limpieza reúne la espera de finalización y la liberación
    env["Entorno de devolución de llamada (TP_CALLBACK_ENVIRON)"] --> cp["Grupo personalizado (controla el número de hilos)"]
    env --> cg["Grupo de limpieza"]
    env --> obj["Se pasa al crear work / timer / wait / io"]
    cg -.-> close["Esperar la finalización y liberar en bloque"]

Figura 11: Un entorno de devolución de llamada es el mecanismo que inyecta en la creación del objeto «en qué grupo se ejecuta y quién limpia».

6.3 Reúna la espera de finalización y la liberación de varios objetos

Cuando work, timer y otros objetos se multiplican dentro de un módulo, el apagado se convierte en una lista de «esperar cada uno, cerrar cada uno». Si crea un grupo con CreateThreadpoolCleanupGroup y hace miembros a los objetos creados a través del entorno de devolución de llamada, un solo CloseThreadpoolCleanupGroupMembers reúne la espera de finalización y la liberación de todos los objetos miembros.⁴⁶

También aquí el objetivo es no dejar atrás una devolución de llamada en ejecución. Elija entre apagar los work de uno en uno, como en el capítulo 4, y apagar a nivel de grupo, según el número de objetos que gestione.

7. Uso desde una DLL — no descargue antes que las devoluciones de llamada

7.1 Espere la finalización en una función de apagado explícita, no en DllMain

Lo más peligroso en una DLL es que la DLL se descargue mientras su código de devolución de llamada todavía puede ejecutarse. Si se ejecuta código descargado, se produce una violación de acceso.

La regla básica es dejar de enviar, esperar la finalización de las devoluciones de llamada y cerrar los objetos en la función de apagado explícita de la DLL antes de descargar. Ya sea con las funciones de espera individuales o con el grupo de limpieza del capítulo 6, esta comprobación de finalización no debe omitirse.⁶

No realice esta espera dentro de DllMain. Por su relación con el bloqueo del cargador provoca otro interbloqueo. Consulte el artículo sobre DllMain y el bloqueo del cargador para más detalle.

7.2 Empareje FreeLibraryWhenCallbackReturns con una referencia tomada antes de enviar

Para la situación «esta devolución de llamada es el último trabajo, así que quiero soltar la referencia de la DLL después de que regrese», existe FreeLibraryWhenCallbackReturns.⁴

Sin embargo, esta API por sí sola no impide una descarga antes de que empiece la devolución de llamada. Lo que hace es soltar una referencia de módulo cuando la devolución de llamada en ejecución regresa. Úsela en pareja: tome una referencia de módulo para ese procesamiento con GetModuleHandleEx antes de enviar, y suéltela desde la devolución de llamada con esta API.

flowchart TB
    accTitle: Cerrar la DLL en una función de apagado frente a devolver una referencia desde la devolución de llamada
    accDescr: La forma básica es una función de apagado distinta de DllMain que detiene los envíos, espera la finalización y libera antes de descargar la DLL; en un diseño en el que la última devolución de llamada devuelve la referencia, tomar la referencia con GetModuleHandleEx antes de enviar y emparejarla con la liberación tras el retorno mediante FreeLibraryWhenCallbackReturns
    shutdown["Función de apagado explícita"] --> stop["Dejar de enviar, esperar, liberar"]
    stop --> unload["Después descargar la DLL"]
    note["No esperar en DllMain"] -.-> shutdown
    acquire["Tomar una referencia de módulo antes de enviar"] --> submit["Enviar la devolución de llamada"]
    submit --> callback["Programar la liberación dentro de la devolución de llamada"]
    api["FreeLibraryWhenCallbackReturns"] -.-> callback
    callback --> returned["Soltar una referencia después de volver"]

Figura 12: No confunda la espera de finalización en la función de apagado con soltar la referencia tomada para la devolución de llamada; en ambos casos, diseñe primero la vida de la DLL.

8. Resumen — empiece por work y sustituya junto con el apagado

El grupo de hilos de Win32 es la base que cambia la concurrencia en código nativo de «crear hilos» a «entregar trabajos como devoluciones de llamada». Puede consolidar los trabajos de corta duración y los hilos que solo esperan, y dejar la gestión de hilos al sistema operativo.

La adopción puede ser gradual. Primero, con work, hacer de la creación, el envío, detener los envíos, esperar la finalización y la liberación un conjunto. A continuación, sustituir los hilos que solo esperan por wait, y los hilos que solo temporizan por timer. Considere la integración de io y la división de grupos cuando resulten necesarias.

flowchart TB
    accTitle: Migrar el código existente al grupo de hilos por etapas
    accDescr: Revisar los hilos autogestionados existentes, conservar el trabajo que encaja en la biblioteca estándar o en un hilo dedicado, pasar el trabajo adecuado al grupo a work incluyendo detener los envíos y esperar la finalización, y sustituir por etapas las esperas por wait y los temporizadores por timer
    inventory["Revisar los hilos autogestionados existentes"] --> choose{"¿Encaja en el grupo?"}
    choose -->|"No"| keep["Elegir biblioteca estándar o dedicado"]
    choose -->|"Sí"| work["Pasar a work, apagado incluido en el conjunto"]
    work --> more["Esperas a wait, temporizadores a timer"]
    more --> optional["Integración de E/S y división de grupos según haga falta"]

Figura 13: No basta con reducir hilos; completar el apagado en cada etapa es la base de una migración gradual.

Lo que se mantiene hasta el final son tres disciplinas: no bloquear durante mucho tiempo, no esperar de forma síncrona en el mismo grupo y no contaminar el estado del hilo. En una DLL, además, evite la carrera con la descarga. Deje a C++ estándar o a .NET lo que ellos cubren, y use esta API donde haga falta integración o control específicos de Windows.

Artículos relacionados

• Los entresijos de E/S de Windows (parte 3) — Puertos de finalización de E/S (IOCP) y el grupo de subprocesos de .NET: el sótano de async/await
• Buenas prácticas de multithreading en la práctica — Edición C++
• Buenas prácticas de multihilo en la práctica — Edición C
• Despertares espurios — Por qué las variables de condición despiertan «sin haber sido notificadas» y cómo esperar correctamente en Windows
• DllMain y el bloqueo del cargador — La razón real de que le digan «no haga nada en la inicialización de la DLL»
• Por qué priorizar la espera por eventos sobre Sleep(1) en Windows

Áreas de consultoría relacionadas

KomuraSoft LLC se encarga del diseño de migración de código nativo cuyos hilos han proliferado hacia el grupo de hilos, de revisiones de diseño del procesamiento concurrente en aplicaciones y DLL de C++, y de la investigación de la causa de cuelgues y fallos provocados por hambruna del grupo o por devoluciones de llamada. Puede consultarnos empezando por un inventario del código existente.

• Desarrollo de aplicaciones Windows
• Consultoría técnica y revisión de diseño
• Investigación de fallos y análisis de causas
• Contacto

Referencias

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Servicios relacionados con este tema

El artículo está directamente relacionado con los siguientes servicios.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

¿Qué tiene de mejor un grupo de hilos frente a crear hilos propios con CreateThread?

La eficiencia cuando hay que procesar un gran número de trabajos de corta duración, y menos código de gestión de hilos. Crear y destruir un hilo tiene un coste que no se puede ignorar. Una aplicación que repite «CreateThread por cada trabajo y destruirlo al terminar», o que mantiene muchos hilos que solo duermen para esperar un evento, puede reducir el número de hilos y los cambios de contexto al pasar a un grupo. La documentación oficial también enumera como candidatas a un grupo las aplicaciones que emiten en paralelo un gran número de elementos de trabajo pequeños, las que crean muchos hilos de corta duración y las que tienen hilos dedicados únicamente a esperar objetos del kernel. A la inversa, el trabajo en el que «el propio hilo necesita una personalidad» —un cambio de prioridad, una STA de COM, un procesamiento dedicado de larga duración— debe seguir en un hilo dedicado como hasta ahora.

¿En qué se diferencia de las funciones antiguas del grupo de hilos como QueueUserWorkItem?

El grupo de hilos se rediseñó por completo en Windows Vista. Las API actuales de la familia threadpoolapiset (CreateThreadpoolWork y similares) son la API nueva; QueueUserWorkItem, RegisterWaitForSingleObject y similares son la API antigua (heredada). La API nueva unifica los tipos de hilo trabajador, permite crear varios grupos independientes en un proceso y ofrece mecanismos como la liberación masiva mediante un grupo de limpieza y la liberación de un bloqueo o la descarga de una DLL ligada a la finalización de la devolución de llamada. La documentación oficial también indica que la API nueva es más sencilla y superior en fiabilidad, rendimiento y flexibilidad. La API antigua tiene además restricciones estructurales, como «no hay forma de cancelar un trabajo una vez encolado», así que en código nuevo use la API nueva.

¿Hay cosas que no se deben hacer dentro de una devolución de llamada?

Hay tres principales. Primera: bloquear durante mucho tiempo o ejecutar un procesamiento largo con los valores predeterminados. El grupo ajusta su número de hilos asumiendo que las devoluciones de llamada terminan pronto; para un procesamiento largo, declárelo con CallbackMayRunLong o use un hilo dedicado. Segunda: esperar de forma síncrona la finalización de otro trabajo enviado al mismo grupo. Si todos los trabajadores terminan «esperando a otro trabajador», se produce un interbloqueo por hambruna del grupo. Tercera: depender de la personalidad del hilo. Los hilos trabajadores se comparten entre devoluciones de llamada; devolver con una prioridad de hilo o un estado de inicialización COM cambiados, o dejar estado en TLS, contamina la siguiente devolución de llamada. Para la limpieza al final (liberar un bloqueo o descargar una DLL) se ofrecen mecanismos dedicados como LeaveCriticalSectionWhenCallbackReturns y FreeLibraryWhenCallbackReturns.

¿Hay puntos a vigilar al usar el grupo de hilos dentro de una DLL?

El mayor peligro es «la DLL se descarga mientras una devolución de llamada todavía puede ejecutarse». Si la devolución de llamada se ejecuta después de la descarga, se produce una violación de acceso. En su procesamiento de apagado, la DLL debe esperar de forma fiable la finalización de las devoluciones de llamada que emitió —con una función de espera como WaitForThreadpoolWorkCallbacks, o CloseThreadpoolCleanupGroupMembers en un grupo de limpieza— antes de cerrar los objetos. Esperar esto dentro de DllMain, sin embargo, puede interbloquearse por interacción con el bloqueo del cargador, así que la regla es hacerlo en una función de apagado explícita, no en DllMain. Para el caso en que la propia devolución de llamada es «el último trabajo» y quiere liberar la DLL, se ofrece una API dedicada, FreeLibraryWhenCallbackReturns.

Ahora que C++ tiene std::async y .NET tiene ThreadPool, ¿sigue habiendo ocasiones para usar esta API de forma directa?

Sí. El criterio es «si basta la herramienta de esa capa». Si la granularidad de concurrencia que se necesita en C++ la cubren std::async o std::thread, la biblioteca estándar es la primera candidata también desde el punto de vista de la portabilidad. Por otro lado, querer unificar temporizadores, esperas de objetos del kernel y finalizaciones de E/S asíncrona en un solo mecanismo de devolución de llamada; querer dividir grupos y controlar el número de hilos por tipo de trabajo; no querer mantener hilos propios dentro de una DLL o un componente COM: esos requisitos son el ámbito del grupo de hilos de Win32. La relación con el ThreadPool de .NET y IOCP se trata en un artículo relacionado, y mientras se escriba nativo, conocer este mecanismo que está en la capa de debajo no es tiempo perdido.

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.