Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
Este artigo fornece informações sobre os relatórios cronológicos na vista de Threads do Visualizador de Concorrência.
Tempo de execução (Vista de Threads)
Esses segmentos na linha do tempo da Exibição de Threads representam o tempo de execução, quando o thread está trabalhando ativamente em um núcleo lógico no sistema.
Alterações no estado da thread são detetadas por meio de eventos de mudança de contexto do kernel. O Rastreamento de Eventos para Windows (ETW) captura pilhas de amostras a cada milissegundo. Num segmento verde muito curto, é possível que não seja colhida amostra. Portanto, alguns segmentos de execução curta podem não mostrar nenhuma pilha de chamadas.
Quando você clica em um segmento de execução, o Visualizador de Simultaneidade exibe a pilha de exemplos mais próxima do local do clique. O local dessa pilha de amostras é indicado por uma flecha preta, ou circunflexo, acima da linha do tempo, e a pilha de amostras aparece no separador Atual.
Para ver um perfil de amostragem tradicional para todos os segmentos de execução na exibição atual, clique em Execução no Perfil da Linha do Tempo Visível.
Tempo de E/S (Visualização de threads)
Esses segmentos na linha do tempo estão associados a tempos de bloqueio categorizados como E/S. Isso significa que um thread está aguardando a conclusão de uma operação de E/S. A thread pode ter sido bloqueada numa API ou por uma espera do kernel relacionada a E/S que o Visualizador de Concurrency está a contar como E/S. APIs como CreateFile(), ReadFile()e WSARecv() se enquadram nesse grupo.
Tempo de gerenciamento de memória
Esses segmentos na linha do tempo estão associados a tempos de bloqueio categorizados como Gerenciamento de Memória. Esse cenário implica que um thread é bloqueado por um evento associado a uma operação de gerenciamento de memória, como a paginação. Durante este período, uma thread foi bloqueada em um estado de API ou de kernel que o Visualizador de Simultaneidade está considerando como gerenciamento de memória. Isso inclui eventos como paginação e alocação de memória.
Examine as pilhas de chamadas associadas e os relatórios de perfil para entender melhor os motivos subjacentes para blocos categorizados como Gerenciamento de Memória.
Tempo de preempção
Esses segmentos na linha do tempo estão associados ao tempo de bloqueio que é categorizado como Preempção. Esta categoria implica que um thread é trocado devido a um destes motivos:
O agendador o substituiu usando um thread de prioridade mais alta.
O quantum de execução do thread expirou e outros threads estavam prontos para serem executados.
Durante esse tempo, um thread foi bloqueado por um motivo de espera do kernel que o Visualizador de Simultaneidade está contando como Preempção. Os segmentos de preempção começam quando um thread é empurrado para fora de um núcleo lógico e terminam quando esse thread retoma a execução.
A dica de ferramenta para um segmento antecipado exibe o nome do processo ou thread que causou a preempção. No entanto, isso não implica que o processo ou thread que assumiu o controle tenha realmente sido executado durante todo o período pré-emptado.
Tempo de sono
Esses segmentos na linha do tempo estão associados ao tempo de bloqueio que é categorizado como Modo de Espera. A categoria sono implica que um fio desistiu voluntariamente de seu núcleo lógico e não está fazendo nenhum trabalho. Durante esse tempo, um thread foi bloqueado em uma API que o Visualizador de Simultaneidade está contando como Suspensão. APIs como Sleep() e SwitchToThread() se enquadram nesse grupo.
Tempo de sincronização
Esses segmentos na linha do tempo estão associados a tempos de bloqueio categorizados como Sincronização. Quando um thread é marcado como bloqueado na sincronização, uma destas coisas está implícita:
A execução do thread pode ter resultado em uma chamada para uma API de sincronização de thread bem conhecida, como
EnterCriticalSection()ouWaitForSingleObject().O algoritmo de correspondência de API não pode ser totalmente abrangente e, portanto, algumas APIs que poderiam ser mapeadas para outras categorias também podem aparecer como sincronização porque um quadro na pilha de chamadas eventualmente atingiu uma primitiva de bloqueio de kernel subjacente que foi mapeada para essa categoria.
Para entender a causa subjacente de um evento de bloqueio de thread, examine cuidadosamente as stacks de chamadas bloqueadas e os relatórios de perfilagem.
Tempo de processamento da interface do usuário
Esses segmentos na linha do tempo estão associados a tempos de bloqueio categorizados como Processamento da Interface de Utilizador. Isso implica que um thread está bombeando mensagens do Windows ou executando outro trabalho de interface do usuário (UI). Durante este tempo, uma thread foi bloqueada numa API que o Visualizador de Simultaneidade está a contar como Processamento da Interface de Utilizador. APIs como GetMessage() e MsgWaitForMultipleObjects() se enquadram nesse grupo.
Se nenhuma API de bloqueio predefinida for identificada, revise as pilhas de chamadas e os relatórios de perfil para determinar as causas subjacentes do atraso.
A categoria Processamento da interface do usuário ajuda você a entender a capacidade de resposta dos aplicativos GUI e é desejável em aplicativos que dependem da capacidade de resposta da interface do usuário. Por exemplo, se o thread da interface do usuário em um aplicativo atingir 100% de tempo no processamento da interface do usuário, ele provavelmente será responsivo. No entanto, se o thread da interface do usuário passar tempo considerável em outras categorias, procure as causas raiz e considere opções para reduzir as categorias que não são da interface do usuário nesse thread.