Falha de sincronização quando estiver depurando

Threads aguardando um objeto de sincronização não podem ser lançados (por exemplo, por PulseEvent() ou uma combinação de SetEvent()/ResetEvent()) enquanto você está depurando um aplicativo no Windows NT.

Esse sintoma é uma anomalia relacionada ao ambiente de depuração em Win32. Ele só ocorrerá em um depurador Win32, incluindo qualquer versão do depurador do Visual C++ e do WinDBG.

Colocar Sleep(0) antes que as chamadas PulseEvent() ou SetEvent()/ResetEvent() provavelmente irão evitar esse problema, mas isso não é garantia de um. Infelizmente, não há nenhuma solução alternativa garantida para essa situação.

Observe que esse sintoma não é um bug, mas em vez disso, um efeito colateral de depuração no Windows NT. Não existem planos para alterar esse comportamento atuais. Também é importante observar que este anomalias não ocorrerá fora de um ambiente de depuração.

PulseEvent() pode falhar ao liberar um thread em espera em um objeto de evento enquanto o aplicativo está sendo executado em um ambiente de depuração. Isso é verdadeiro independentemente de estarem ou não o código é compilado com informações de depuração. Isso também é independentemente se o debuggee é executado pelo comando "Ir" ou pelo sendo "único passado"

O problema é mais provável de ocorrer se mais de um segmento está aguardando o mesmo evento. Falha ao liberar o segmento em espera se torna mais provável ainda se há eventos de depuração que ocorrem nesses threads, tais como aqueles causados por OutputDebugString(). Fazer uma chamada para OutputDebugString() diretamente antes de uma chamada para PulseEvent() é uma maneira eficaz de regularmente fazendo com que um segmento em espera não para acordar no ambiente de depuração.

Isso acontece porque o ambiente de depuração do Win32 normalmente suspende threads. Quando isso acontece, ele recebe o thread fora do seu estado atual e faz com que ele esperar em um evento de "suspender". Esse tipo de suspensão internamente acontece em cada evento de depuração. Quando reiniciado, os threads são colocados voltar em seu estado de espera anterior. Se o PulseEvent() ocorre enquanto um segmento está em um estado suspenso de depuração, a discagem de pulso é perdida para esse segmento. Isso também é verdadeiro de um thread suspenso pelo aplicativo usando SuspendThread().

Esse comportamento não está limitado a PulseEvent(). Threads aguardando são suscetíveis a "depuração suspender" em outros cenários Além disso, incluindo um par de SetEvent()/ResetEvent() rápido.

Como mencionado acima, uma possível solução para esse problema é colocar uma chamada Sleep(0) antes de qualquer chamada PulseEvent() ou SetEvent(). Este procedimento resolve o problema na maioria dos casos, porque ele permite que segmentos sendo reiniciado uma oportunidade para iniciar aguardando novamente.

É importante observar que este anomalias não ocorrerá fora de um ambiente de depuração.