Threads de notificação na API de criação de perfil
Na maioria dos casos, o thread que gera um evento também executa as notificações. Tais notificações (por exemplo, FunctionEnter and FunctionLeave) não é necessário fornecer o explícita ThreadID. Além disso, o criador de perfil pode decidir usar armazenamento thread local para armazenar e atualizar seus blocos de análise em vez de indexação os blocos de análise de armazenamento global, com base no ThreadID do thread afetado.
Observe que esses retornos de chamada não são serializados. Os usuários devem proteger seu código com a criação de estruturas de dados de thread-safe e bloqueando o código de criador de perfil onde for necessário para impedir o acesso paralelo de vários segmentos. Portanto, em alguns casos, você pode receber uma sequência incomuns de retornos de chamada. Por exemplo, suponha que um aplicativo gerenciado está gerando dois segmentos que estão executando código idêntico. Nesse caso, é possível receber um ICorProfilerCallback::JITCompilationStarted evento alguma função de um thread e um FunctionEnter retorno de chamada do thread antes de receber o ICorProfilerCallback::JITCompilationFinishedretorno de chamada . Nesse caso, o usuário receberá um FunctionEnter retorno de chamada para uma função que pode não ter sido totalmente just-in-time (JIT) compilado ainda.