Pooling de thread
Há muitos aplicativos que criam threads que passam muito tempo no estado de suspensão aguardando a ocorrência de um evento. Outros threads podem entrar em um estado de suspensão apenas para serem acordados periodicamente para sondar uma alteração ou atualizar informações de status. O pool de threads permite que você use threads com mais eficiência fornecendo ao aplicativo um pool de threads de trabalho gerenciados 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, um thread de trabalho do pool de threads executa a função de retorno de chamada 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 Pools de Threads.
Você também pode enfileirar itens de trabalho que não estão relacionados a uma operação de espera para o pool de threads. Para solicitar que um item de trabalho seja manipulado por um thread no pool de threads, chame a função QueueUserWorkItem . Essa função leva um parâmetro para a função que será chamada pelo thread selecionado no pool de threads. Não há como cancelar um item de trabalho após ele ter sido enfileirado.
Os temporizadores de fila de temporizador e as operações de espera registradas também usam 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, o retorno de chamada é executado por um thread do pool de threads.
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 usa o tamanho da pilha padrão e é executado na 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 em threads de trabalho de E/S como chamadas de procedimento assíncrono (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 é de E/S aguarda as portas de conclusão de E/S. Usar threads de trabalho que não são de E/S é mais eficiente do que usar threads de trabalho de E/S. Portanto, você deve usar threads de trabalho que não são de E/S sempre que possível. Os threads de trabalho de E/S e não E/S não serão encerrados se houver solicitações de E/S assíncronas pendentes. Ambos os tipos de threads podem ser usados por itens de trabalho 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 que não sejam de E/S se elas 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 seguros no pool de threads. Uma função segura não pressupõe que o thread em execução seja um thread dedicado ou persistente. Em geral, você deve evitar usar o armazenamento local do thread ou fazer uma chamada assíncrona que exija um thread persistente, como a função RegNotifyChangeKeyValue . No entanto, essas funções podem ser chamadas em um thread dedicado (criado pelo aplicativo) ou enfileiradas em um thread de trabalho persistente (usando QueueUserWorkItem com a opção WT_EXECUTEINPERSISTENTTHREAD).
Tópicos relacionados