Utilização de memória local threads num procedimento armazenado expandido

O armazenamento local de thread (TLS) pode ser um assunto muito difícil. Quando trabalha num thread de agrupamento de ambiente, é muito importante que compreenda as consequências da TLS e as interacções de thread.

Recomenda-se muito, evitar TLS num thread agrupamento ambiente como o Microsoft SQL Server. No entanto, se deve utilizar TLS, verifique cuidadosamente ler este documento e consulte a documentação online no SDK do Win32 para as funções principais TLS e DLL.

Além disso, o __declspec(thread) directiva de compilador não é suportada num procedimento armazenado expandido. Quando ocorre LoadLibarary, a definição __declspec(thread) não está inicializada correctamente. Consulte "Windows Advanced" por Jeffrey Ricter para obter mais detalhes.



NOTA: Qualquer extensão do SQL Server, incluindo procedimentos armazenados estendidos, nunca poderá fazer uma chamada para DisableThreadLibraryCalls().

Conforme é documentado, a função de TlsAlloc devolve um valor de índice é utilizado em chamadas de função para TlsSetValue e TlsGetValue. A documentação sugere que chamar a função TlsAlloc na sua função DLLMain quando ul_reason_for_call = DLL_PROCESS_ATTACH. Por predefinição, DLL_PROCESS_ATTACH é chamado quando a DLL é carregada inicialmente.

Em DLL_PROCESS_ATTACH e DLL_THREAD_ATTACH, deve atribuir memória e chamar TlsSetValue. Trata-se especificamente onde o thread de agrupamento começa a causar alguns problemas no cenário.

Segue-se um cenário de exemplo que se aplica a qualquer aplicação que thread de agrupamento. Este exemplo utiliza a aplicação do Microsoft SQL Server.

Seguem-se algumas noções básicas para o exemplo que é necessário compreender. Todas estas estão documentadas mais detalhadamente na documentação do Win32 SDK em função DLLMain.

• Quando uma DLL é carregada, ele chama DLL_PROCESS_ATTACH.
• Todos os segmentos subsequentes (gerados depois da DLL é carregada) chamada DLL_THREAD_ATTACH.
• Threads actualmente em execução (geradas antes da DLL está carregada) não chamar DLL_THREAD_ATTACH.
• Todos os threads chamar DLL_THREAD_DETACH, mesmo que nunca chamados DLL_THREAD_ATTACH.

Por exemplo, suponha que o gráfico seguinte mostra a ordem e a utilização do conjunto de threads de trabalho do SQL Server:

João inicia uma instrução select de execução longa. Ninguém tem utilizado xp_test expandido o procedimento armazenado, por isso não é possível para o processo DLL_ATTACH a ser chamado.

Durante a execução seleccione de José, Maria executa xp_test. O thread de agrupamento mecanismo determina que um novo thread deve ser gerado a pedido Maria serviço. SQL Server, em seguida, chama a função LoadLibrary para carregar o ficheiro Xproc.dll. Ao fazê-lo, thread 2 é o primeiro thread para anexar a DLL para DLL_PROCESS_ATTACH é designado por. Tal como discutido anteriormente, TlsAlloc pode ser chamado para inicializar o valor de índice do procedimento armazenado expandido TLS.

Durante a execução de João e a de Maria comandos, ADAM submete o seu próprio seleccione. Novamente, um novo thread é gerado para processar o pedido de ADAM. Uma vez que é gerado thread 3 depois do LoadLibrary teve lugar, thread 3 chamadas DLL_THREAD_ATTACH. Conforme é documentado, é onde deve atribuir a memória para thread 3 e chamar TlsSetValue.

Agora, suponha que seleccione José concluída, thread de trabalho 1 é livre para utilização. Lynn submete o comando xp_test e é atribuído o thread 1. Thread 1 chamadas nunca DLL_PROCESS_ATTACH ou DLL_THREAD_ATTACH, porque o thread foi gerado antes do LoadLibrary foi chamado.

Neste exemplo, pode ver que qualquer tentativa por thread 1 aceder à memória TLS com TlsGetValue resultará num apontador NULL devolvido. Se o procedimento armazenado expandido não está escrito correctamente para verificar se esta condição, encontrará uma violação de acesso (AV) quando tenta escrever o endereço de NULL.

Seguem-se vários pontos que necessitam de ser mencionado sobre TLS e o thread de agrupamento.

Se estiver a utilizar TLS num ambiente de agrupamento, terá de verificar sempre TlsGetValue para um valor de retorno nulo. Quando chegar um NULL, correctamente tem de atribuir memória e chamada TlsSetValue para processar os threads que onde gerada antes do LoadLibrary teve lugar.

Outro truque directamente não resolvido a documentação é que irá atribuir a memória TLS na função DLLMain para cada thread gerado depois LoadLibarary, mesmo que o thread nunca utiliza as funções na DLL. O exemplo acima mostra este com thread 3. -Executado apenas uma selecção, mas esta chamada DLL_THREAD_ATTACH atribuída memória TLS para o procedimento armazenado expandido.

Se colocar esta estrutura de um thread de agrupamento de ambiente, poderá atribuir a memória que nunca pode ser utilizada.

Segue-se a melhor forma para optimizar a atribuição de memória:

1. Em DLL_PROCESS_ATTACH, obter o valor de índice TLS correcto a partir do TlsAlloc.
2. Não atribuir memória DLL_PROCESS_ATTACH ou DLL_THREAD_ATTACH.
3. Criar uma função genérica para obter o valor TLS; se for NULL, atribui-lo correctamente e chamar TlsSetValue.
   
   Este passo restringe a atribuição de memória para os threads que realmente utilização-la. Isto pode reduzir o tempo sobrecarga e de arranque de threads de trabalho significativamente. Também cria em redundância para processar correctamente os módulos que foram gerados antes do LoadLibrary teve lugar.
4. Como DLL_PROCESS_DETACH e DLL_THREAD_DETACH sempre denominam-se, Liberte memória esses processos.

A apenas outra coisa ainda pode ser confusa for chamada TlsAlloc. Ler a documentação, poderá parecer que o valor de índice TLS devolvido é um valor global. É um valor global, mas cada chamada para TlaAlloc devolve um valor de índice diferente. Isto permite que dois procedimentos armazenados estendidos ter seu próprio valor de índice TLS e processar correctamente os seus próprios dados TLS sem afectar os outros.

Segue-se um procedimento armazenado expandido que mostra o comportamento descrito no exemplo:

Mais Informação