Falha de sincronização durante a depuração

Não podem ser libertados threads à espera de um objecto de sincronização (por exemplo, por PulseEvent() ou uma combinação de SetEvent()/ResetEvent()) enquanto estiver a depurar uma aplicação no Windows NT.

Este sintoma é uma anomalia relacionadas com o ambiente de depuração no Win32. Só ocorrerá num depurador Win32, incluindo qualquer versão do depurador do Visual C++ e WinDBG.

Colocar Sleep(0) antes das chamadas PulseEvent() ou SetEvent()/ResetEvent(), provavelmente, irão evitar este problema, mas este não é garantida uma. Infelizmente, não existe não solução garantia para esta situação.

Tenha em atenção que este sintoma não é um erro, mas sim um efeito de lado de depuração no Windows NT. Existem existem planos para alterar este comportamento actuais. Também é importante ter em atenção que esta anomalia não ocorrerá fora de um ambiente de depuração.

PulseEvent() poderá não conseguir libertar um thread em espera um objecto de evento enquanto a aplicação está em execução num ambiente de depuração. Isto acontece independentemente se o código é compilado com informações de depuração. Este é também independentemente se o elemento depurado é executado o comando "ir" ou ser "único utilizado."

O problema é mais provável se mais do que um thread está à espera do mesmo evento. Falha ao lançar o thread em espera torna-se mais provável que ainda se não existirem eventos de depuração que ocorram nestes threads, tais como os causado por OutputDebugString(). Efectuar uma chamada para OutputDebugString() directamente antes de uma chamada para PulseEvent() é uma forma eficaz de regularmente a causar um thread em espera não para acordar no ambiente de depuração.

Isto acontece porque o ambiente de depuração Win32 normalmente suspende threads. Quando isto acontecer, solicita o thread fora do respectivo estado actual e causa a aguardar num evento "suspender". Este tipo de suspensão internamente acontece em todos os eventos de depuração. Quando retomar, os threads são colocados novamente para o estado de espera anterior. Se o PulseEvent() ocorre enquanto um thread está num estado suspenso de depuração, a marcação por impulsos é perdida para esse thread. Isto também acontece de um thread suspenso pela aplicação utilizando SuspendThread().

Este comportamento não está limitado a PulseEvent(). Aguardar threads são susceptíveis à "depuração suspender" em outros cenários, incluindo um par de SetEvent()/ResetEvent() rápido.

Tal como mencionado anteriormente, uma possível solução para este problema consiste em colocar uma chamada Sleep(0) antes de qualquer chamada PulseEvent() ou SetEvent(). Isto resolve o problema na maioria dos casos, porque permite a ser retomado uma oportunidade para iniciar novamente a aguardar threads.

É importante ter em atenção que esta anomalia não ocorrerá fora de um ambiente de depuração.