Pool de threads

Há muitos aplicativos que criam threads que passam muito tempo no estado de suspensão esperando que um evento ocorra. Outras threads podem entrar num estado de suspensão apenas para serem acordadas periodicamente para verificar alterações ou atualizar informações de status. O agrupamento de threads permite que o utilizador use threads de forma mais eficiente, fornecendo à sua aplicação um pool de threads auxiliares geridos pelo sistema. Pelo menos um thread monitora o status de todas as operações de espera enfileiradas no pool de threads. Quando uma operação de espera é concluída, uma thread de trabalho do pool de threads executa a função callback correspondente.

Este tópico descreve a API original do pool de threads. A API do pool de threads introduzida no Windows Vista é mais simples, mais confiável, tem melhor desempenho e fornece mais flexibilidade para os desenvolvedores. Para obter informações sobre a API atual do pool de threads, consulte Thread Pools.

Você também pode enfileirar itens de trabalho que não estão relacionados a uma operação de espera no pool de threads. Para solicitar que um item de trabalho seja manipulado por um thread no pool de threads, chame a funçãoQueueUserWorkItem. Esta função leva um parâmetro para a função que será chamada pelo thread selecionado do pool de threads. Não é possível cancelar um item de trabalho depois de ter sido enfileirado.

temporizadores da fila de temporização e operações de espera registadas também utilizam o pool de threads. Suas funções de retorno de chamada são enfileiradas no pool de threads. Você também pode usar a função BindIoCompletionCallback para postar operações de E/S assíncronas. Após a conclusão da E/S, a callback é executada por uma thread do pool.

O pool de threads é criado na primeira vez que você chama QueueUserWorkItem ou BindIoCompletionCallback ou quando um temporizador de fila de temporizador ou operação de espera registrada enfileira uma função de retorno de chamada. Por padrão, o número de threads que podem ser criados no pool de threads é de cerca de 500. Cada thread utiliza o tamanho padrão da pilha e executa com a prioridade padrão.

Há dois tipos de threads de trabalho no pool de threads: E/S e não-E/S. Um thread de trabalho de E/S é um thread que aguarda em um estado de espera alertável. Os itens de trabalho são enfileirados nas threads de trabalho de E/S, onde atuam como chamadas de procedimento assíncronas (APC). Você deve enfileirar um item de trabalho para um thread de trabalho de E/S se ele deve ser executado em um thread que aguarda em um estado alertável.

Um thread de trabalho que não seja de E/S aguarda nas portas de conclusão de E/S. O uso de threads de trabalho que não sejam de E/S é mais eficiente do que o uso de threads de trabalho de E/S. Portanto, você deve usar threads de trabalho que não sejam de E/S sempre que possível. Os threads de trabalho de E/S e não-E/S não saem se houver solicitações de E/S assíncronas pendentes. Ambos os tipos de threads podem ser usados por tarefas que iniciam solicitações de conclusão de E/S assíncronas. No entanto, evite postar solicitações de conclusão de E/S assíncronas em threads de trabalho não relacionados a E/S se estas puderem levar muito tempo para serem concluídas.

Para usar o pool de threads, os itens de trabalho e todas as funções que eles chamam devem ser compatíveis com o pool de threads. Uma função segura não assume que o thread que a executa é um thread dedicado ou persistente. Em geral, deverá evitar usar armazenamento local de threads ou fazer uma chamada assíncrona que exija uma thread persistente, como a função RegNotifyChangeKeyValue. No entanto, essas funções podem ser chamadas em um thread dedicado (criado pelo aplicativo) ou enfileiradas para um thread de trabalho persistente (usando QueueUserWorkItem com a opção WT_EXECUTEINPERSISTENTTHREAD).

Tópicos relacionados

I/O alertável

Chamadas de procedimento assíncrono

Portas de conclusão de E/S

Pools de threads