Este artigo foi traduzido por máquina.

Desempenho do thread

Criação de perfil de simultaneidade de disputa de recursos no Visual Studio 2010

Maxim Goldin

Como processadores de vários núcleos se tornam cada vez mais comuns, os desenvolvedores de software estão criando aplicativos multithread que tiram proveito da capacidade de processamento adicionais para obter um melhor desempenho. Usando o poder dos segmentos paralelos, você pode dividir o trabalho total em tarefas separadas e executar as tarefas em paralelo.

Threads, no entanto, freqüentemente precisam se comunicar entre si para concluir uma tarefa e, às vezes precisam sincronizar seus comportamentos se exigir um acesso de dados ou algoritmo. Por exemplo, acesso de gravação simultâneo para os mesmos dados devem ter a segmentos de uma maneira mutuamente exclusivo para evitar corrupção de dados.

Sincronização com freqüência é realizada através do uso de objetos de sincronização compartilhado, onde o thread adquirir o objeto é concedido acesso compartilhado ou exclusivo de código confidencial ou dados. Quando o acesso não é mais necessário, o thread abandona propriedade e outros segmentos podem tentar adquirir acesso. Dependendo do tipo de sincronização usado, solicitações simultâneas de propriedade podem permitir que vários threads acessar recursos compartilhados, ao mesmo tempo, ou alguns dos threads poderão ser bloqueada até que o objeto será liberado da aquisição anterior. Exemplos 
include seções críticas em C/C++ que usam EnterCriticalSection e LeaveCriticalSection rotinas de acesso, a função de WaitForSingleObject in C/C++ e a instrução lock e a classe Monitor em c#.

A escolha do mecanismo de sincronização deve ser feita com cuidado, pois sincronização incorreta entre threads pode reduzir em vez de aumentar os ganhos de desempenho são o objetivo de multithreading. Portanto, é cada vez mais importante ser capaz de detectar as situações em que os segmentos são bloqueados devido à contentions de bloqueio que não tornam a nenhum progresso.

As ferramentas de desempenho no Visual Studio 2010 incluem um novo método de perfilação — o profiling de contenção de recursos — que o ajuda a detectar a disputa entre os threads de simultaneidade. Você pode encontrar uma excelente primeira olhada esse recurso na postagem de blog Wintellect ’ John Robbins na wintellect.com/CS/blogs/jrobbins/archive/2009/10/19/vs-2010-beta-2-concurrency-resource-profiling-in-depth-first-look.aspx de .

Neste artigo, eu passar por uma investigação de contenção de perfil e explique os dados que podem ser obtidos usando ferramentas de linha de comando e o IDE do Visual Studio 2010. Também mostrarei como você pode analisar os dados no Visual Studio 2010, e você verá como mover de análise de um modo de exibição para outro ao conduzir a investigação de contenção. Em seguida, eu irá corrigir o código e comparar resultados do aplicativo modificado com os originais criação de perfil para validar que a correção reduz o número de contentions de perfil.

Iniciar com o problema

Por exemplo, usarei o mesmo aplicativo da multiplicação de matriz Hazim Shafi usado na sua mensagem no blogue “ desempenho padrão 1: Identificando a contenção de bloqueio ” (blogs.msdn.com/hshafi/archive/2009/06/19/performance-pattern-1-identifying-lock-contention.aspx do). O exemplo de código é escrito em C++, mas os conceitos, abordarei são igualmente aplicáveis para código gerenciado.

O exemplo de aplicativo de multiplicação de matriz usa vários threads para multiplicar as matrizes de dois. Cada thread obtém uma parte do trabalho e executa o trecho de código a seguir:

for (i = myid*PerProcessorChunk; 
     i < (myid+1)*PerProcessorChunk; 
     i++) {
  EnterCriticalSection(&mmlock);
  for (j=0; j<SIZE; j++) {
    for (k=0; k<SIZE; k++) {
      C[i][j] += A[i][k]*B[k][j];
    }
  }
  LeaveCriticalSection(&mmlock);
}

Cada segmento possui sua própria identificação (myid) e é responsável por calcular o número de linhas (um ou mais) na matriz resultante C, usando matrizes A e B como entrada. Inspeção de código fechar mostra o que acontece sem realmente ambíguo gravação compartilhamento, e cada thread grava uma linha diferente de c. O desenvolvedor ainda decidido Proteja-se a atribuição para a matriz com uma seção crítica. Eu agradecer desenvolvedor para isso, pois ela me dá uma boa oportunidade de demonstrar as novas ferramentas de desempenho do Visual Studio 2010 para localizar com facilidade a sincronização redundante.

A coleta de dados de perfil

Supondo que você tenha um projeto do Visual Studio com o código mostrado anteriormente (embora ele não é necessário — você pode anexar o gerador de perfil para qualquer aplicativo que já está sendo executado), inicie a contenção de perfilação, clicando em Iniciar o Assistente de desempenho, no menu Analyze.

Na primeira página do assistente, mostrado em do Figura 1, escolha a simultaneidade e certificar-se de que a opção “ coletar dados de contenção de recursos ” está marcada. Observe que simultaneidade de contenção de recursos funciona em qualquer versão do sistema operacional Windows de perfil. A opção “ visualização o comportamento de um aplicativo multithreaded ” requer o Windows Vista ou o Windows 7.

Figura 1 de simultaneidade ativando o recurso criação de perfil.

Na segunda página do assistente, verifique se que o projeto atual se destina. Na última página do assistente, certifique-se de “ após a conclusão do Assistente de perfil de lançamento ” esteja marcada e clique em ' Concluir '. O aplicativo começará executando sob o criador de perfil. Quando ele sai, o arquivo de dados de perfil é exibido na janela Performance Explorer (consulte do Figura 2).

Do arquivo de resultados no Performance Explorer de criação de perfil de desempenho, a Figura 2

O relatório de criação de perfil automaticamente abre no Visual Studio e exibe os resultados da investigação de desempenho no modo de exibição Resumo, que é mostrado no do Figura 3.

A Figura 3 do modo de exibição de resumo do relatório de criação de perfil

Análise de dados de perfil

Sincronização não faz com que a contenção de bloqueio. Se houver um bloqueio, uma tentativa de se apropriar do bloqueio não bloqueia a execução de thread e acontece sem contenção. No modo de criação de perfil de contenção de recursos, o criador de perfil coleta dados apenas para eventos de sincronização que causam a contenção e não relata aquisições bem-sucedida do recurso (desbloqueada). Se seu aplicativo não faz com que qualquer contentions, nenhum dado será coletado. Se você receber dados, significa que seu aplicativo tiver bloqueio contentions.

Para cada conflito, os relatórios de gerador de perfil que o thread foi bloqueado, onde o conflito ocorreu (pilha de chamada e de recursos), quando a contenção ocorreu (carimbo de hora) e o período de tempo (comprimento) que o thread foi bloqueado a tentativa de adquirir um bloqueio, inserir uma seção crítica, aguarde até que um único objeto e assim por diante.

Quando você abre o arquivo, você verá primeiro o modo de exibição Resumo ( do Figura 3), com três áreas principais que você pode usar para breve de diagnóstico:

1. O gráfico contentions mostra o número de contentions por segundo plotado durante a vida útil do seu aplicativo. Picos de contenção de inspecionar visualmente ou selecione um intervalo de tempo e um zoom nela ou filtrar os resultados. A filtragem re-analyzes os dados e remove os dados fora do intervalo selecionado.
2. A tabela de recursos mais disputada lista os recursos que causou os contentions mais detectados.
3. A tabela de segmentos mais disputada relaciona os threads com o maior número de contentions. Esta tabela usará o número de contentions como critério, não o comprimento das contentions. Portanto, talvez você tenha um thread é bloqueado em uma única disputa por um longo tempo, mas não serão exibido no modo de exibição Resumo. Por outro lado, um thread que teve muitos contentions muito curtos, com cada contenção de bloqueio do thread para apenas um tempo muito curto, poderia ser apresentado no modo de exibição Resumo.

Se você vir um recurso é responsável por grande parte da contentions, inspecione o recurso mais detalhadamente. Se você observar um thread que passa por um grande número de contentions que não esperava, inspecione os contentions do thread.

Por exemplo, do Figura 3, você pode ver que a seção crítica 1 é responsável por quase todos os contentions (99.90 por cento) nesse aplicativo. Let’s investigar mais de perto desse recurso.

Nomes de recursos e as identificações de segmento no modo de exibição Resumo são hiperlinks. Clicando nas transferências de seção crítica 1 para os detalhes do recurso Visualizar (consulte do Figura 4), onde o contexto é definido para o recurso específico — 1 da seção crítica.

Do modo de exibição de detalhes do recurso, a Figura 4

Detalhes do recurso

A parte superior do modo de exibição de detalhes do recurso mostra um gráfico com base no tempo em que cada linha horizontal pertence a um thread. As linhas são chamadas pela função thread raiz, a menos que você nomeia o thread gerenciado no seu código (por exemplo, usando a propriedade System.Threading.Thread.Name em c#). Um bloco nessa linha representa uma contenção do thread no recurso. O tamanho de bloco é o comprimento de contenção. Blocos de linhas diferentes podem se sobrepor a tempo, o que significa que vários threads bloqueados no recurso ao mesmo tempo.

A linha de total é especial. Ele não pertence a nenhum segmento específico, mas contém todos os contentions de todos os threads nesse recurso (ele é realmente uma projeção de contenção de blocos para a linha). Como você pode ver, seção crítica 1 estava muito ocupado, não parece ter qualquer slots vazios na sua linha de total.

Você pode aplicar zoom em uma parte específica do gráfico, selecionando um intervalo de tempo com o botão esquerdo do mouse (clique no ponto no gráfico que você deseja iniciar e, em seguida, arraste o ponteiro para a direita). Há dois vínculos na parte superior direita do gráfico — zoom redefinir e aplicar zoom para fora. Redefinir zoom restaura o modo de exibição do gráfico original. Leva que você volta etapa por etapa, un-zooming o gráfico da mesma forma que você acabou de ampliar o zoom.

O padrão geral de blocos de contenção pode causar a algumas conclusões sobre a execução do aplicativo. Por exemplo, você pode ver que contentions de vários segmentos estão muito sobrepostos no tempo, o que indica um menor que a paralelização ideal. Cada thread está bloqueado no recurso muito mais do que está sendo executado e ainda é outra indicação da ineficiência do aplicativo.

Detalhes da função

A parte inferior do modo de exibição de detalhes do recurso é uma pilha de chamadas de contenção, nenhum dado será exibido até que você selecione um conflito específico. Quando você seleciona um bloco, a pilha correspondente aparece no painel inferior. Você também pode focalizar um bloco de contenção no gráfico sem clicar nele e uma janela pop-up fornecerá a pilha e o comprimento de contenção.

Como você pode ver na pilha de chamadas de contenção, uma das funções de aplicativo de exemplo chamado MatMult estiver listado, para que você saiba que ele era a causa o conflito. Para determinar qual linha do código de função é responsável pela contenção, clique duas vezes no nome da função no painel de pilha de chamada. Que leva você para o modo de exibição de detalhes da função mostrado do Figura 5.

Do modo de exibição de detalhes da função, a Figura 5

Este modo de exibição, você verá uma apresentação gráfica das funções que chamaram MatMult, bem como funções que foram chamadas dentro do mesmo. A seção inferior do modo de exibição mostra claramente que EnterCriticalSection(&mmlock) é responsável por threads que estão sendo bloqueados o tempo todo.

Quando você sabe que linha do seu código é responsável por contentions, você poderá reconsiderar sua decisão para implementar a sincronização desse modo. É a melhor maneira de proteger seu código? É a proteção necessárias em todos os?

No aplicativo de exemplo, usar uma seção crítica, esse código é desnecessário pois segmentos Don compartilham gravações às linhas da matriz mesmo resultado. As ferramentas de desempenho do Visual Studio oferecem o ponto onde é possível comentar o uso de mmlock, significativamente, acelerando o aplicativo. Se apenas sempre foi muito fácil!

Para obter uma descrição mais detalhada do modo de exibição de detalhes da função, consulte o blog da equipe de criador de perfil do Visual Studio de blogs.msdn.com/profiler/archive/2010/01/19/vs2010-investigating-a-sample-profiling-report-function-details.aspx .

Detalhes de thread

Como mencionei anteriormente, o modo de exibição Resumo fornece um bom ponto de partida para a sua investigação. Examinando as tabelas de recursos mais disputada e mais disputada threads, você pode decidir como proceder. Se você achar que um dos threads parecerem suspeito porque você não esperava que estejam na lista de threads disputados superior, você pode decidir dar o segmento de uma análise mais detalhada.

Clique na identificação de segmento no modo de exibição Resumo para ir até os detalhes do thread de ler (consulte do Figura 6). Embora esse modo de exibição é semelhante ao modo de exibição de detalhes do recurso, ele tem um significado diferente porque ela exibe contentions no contexto do segmento selecionado. Cada linha horizontal representa um recurso que o thread foi disputando durante o tempo de vida do segmento. Neste gráfico, você não verá os blocos de contenção sobrepondo-se no momento porque o que significa que o mesmo thread foi bloqueado em mais de um recurso ao mesmo tempo.

Figura 6 de thread com bloqueio de contenção selecionados no modo de exibição Detalhes

Observe que WaitForMultipleObjects (que eu não estou mostrando aqui) é tratada separadamente e é representado com uma linha de gráfico único para o conjunto de objetos. Isso ocorre porque o gerador de perfil trata todos os objetos de parâmetro de WaitForMultipleObjects como uma entidade única.

As manipulações, que você pode fazer no modo de exibição de detalhes de recursos (zoom no gráfico de entrada e saída, selecionando contentions específicos e exibir a duração em milissegundos e a pilha de chamada) são aplicáveis à visualização detalhes do thread. Clique duas vezes no nome da função no painel pilha de chamadas de contenção para navegar para o modo de exibição de detalhes da função dessa função.

No exemplo, você pode ver que o thread gasto mais tempo do que está sendo bloqueado de em execução no início da execução do e, em seguida, ele será bloqueado por um longo tempo em um conjunto de várias alças. Como o último bloco é causado por que estão aguardando a conclusão de outros segmentos, contentions anteriores indicam o uso não ideal do thread, fazendo com que o thread estar em um estado bloqueado mais do que em um estado de execução.

Perseguindo para baixo o problema

Como você deve ter notado, os rótulos de eixo do gráfico são hiperlinks. Isso permite alternar entre modos de exibição detalhados dos recursos e threads, definindo o contexto necessário para o modo de exibição de cada vez. Isso pode ser útil para uma abordagem iterativa para localizar e resolvendo um problema. Por exemplo, você pode inspecionar R1 bloqueado muitos segmentos de recurso. Você pode ir de detalhes do recurso Visualizar uma exibição detalhada de thread T1 e descobrir que ele foi bloqueado não apenas em R1, mas às vezes, também no recurso R2. Você pode me aprofundar nos detalhes do R2 e observar todos os threads que foram bloqueados por R2. Próxima, você pode clicar no rótulo do thread T2 chama sua atenção para verificar se todos os recursos de que bloqueou T2, e assim por diante.

Contenção de dados de perfil não lhe dá uma resposta explícita para a pergunta sobre o que está mantendo um bloqueio em um determinado momento. Mas o dado justo o uso do objeto de sincronização entre segmentos e seu conhecimento sobre o comportamento do aplicativo, você pode identificar um possível proprietário (um thread bem-sucedidos na aquisição de bloqueio de sincronização), dinamizar seus dados de detalhes do recurso para detalhes de thread e de volta.

Por exemplo, suponha que no modo de exibição Detalhes do thread, que você vê um thread T é bloqueado no recurso R em vez de t. Você pode alternar para o modo de exibição de detalhes do recurso da pesquisa clicando-se o rótulo de R e ver todos os threads que foram bloqueados no R durante o tempo de vida do aplicativo. Em vez t, você verá um número deles (incluindo T) bloqueado na r. Um thread que não esteja bloqueado em pesquisa em vez t for um proprietário de bloqueio possível.

Observei anteriormente que a linha de total do gráfico é uma projeção de todos os blocos de disputa. O rótulo total é também um hiperlink, mas na modo de exibição de detalhes de recursos que ele leva você para a disputa por exibir (consulte do Figura 7), que é uma coleção de árvores de chamada de disputa por recurso. O caminho ativo da árvore de chamada apropriados do recurso está ativado para você. Esta exibição mostra contentions e estatísticas de tempo de bloqueio para cada recurso e para cada nó (função) na árvore de chamada de recursos. Ao contrário dos outros modos, esta agrega pilhas de contenção, na árvore de chamada do recurso, assim como nos outros modos de criação de perfil e fornece estatísticas para toda a execução do aplicativo.

A Figura 7 do modo de exibição de contenção com o Hot Path aplicada à 1 da seção crítica

No modo de exibição de contenção, você pode voltar para o modo de exibição de detalhes de recursos de qualquer recurso usando o menu de contexto. Apontar para um recurso, clique com o botão direito do mouse e selecione Mostrar detalhes de recursos de contenção. Outras ações interessantes também estão disponíveis no menu de contexto. Como uma sugestão geral, explore os menus de contexto nos modos de exibição do criador de perfil — eles podem ser bastante útil!

Clique no rótulo total do modo de exibição de detalhes do thread para o modo de exibição processos, onde o thread está marcado (consulte do Figura 8). Neste modo de exibição que você possa ver quando o thread foi iniciado em relação à hora de início aplicativo, quando ela foi finalizada, quanto tempo ela ficou, quantos contentions experiente e quanto tempo foi bloqueado em todos os contentions (em milissegundos e em porcentagem do tempo de vida do segmento).

Do modo de exibição processos, a Figura 8

Novamente, é possível voltar para o modo de exibição de detalhes de thread para qualquer thread, usando o menu de contexto — selecione um segmento de seu interesse, com o botão direito e selecione Mostrar detalhes de disputa por thread.

Outro fluxo de investigação de possíveis seria para o modo de exibição processos diretamente quando o arquivo for aberto, classificar os threads, clicando no título de uma das colunas disponíveis (por exemplo, classificação threads pelo número de contentions), selecione um dos threads e, em seguida, alterne para o gráfico de detalhes de contenção do thread através do menu de contexto.

Corrigir o problema e comparar resultados

Após localizar a causa dos contentions bloqueio do aplicativo, você pode comente a seção crítica mmlock e, em seguida, execute novamente a criação de perfil:

for (i = myid*PerProcessorChunk; 
     i < (myid+1)*PerProcessorChunk; 
     i++) {
  // EnterCriticalSection(&mmlock);
  for (j=0; j<SIZE; j++) {
    for (k=0; k<SIZE; k++) {
      C[i][j] += A[i][k]*B[k][j];
    }
  }
  // LeaveCriticalSection(&mmlock);
}

Você poderia esperar o número de contentions para diminuir e perfil de fato da código modificado relatórios somente uma contenção de bloqueio, conforme mostrado no do Figura 9.

Do modo de exibição de resumo dos resultados da criação de perfil de código fixo, a Figura 9

Nós também pode comparar os resultados de desempenho de novas e anteriores do Visual Studio. Para fazer isso, selecione os dois arquivos no Performance Explorer (Selecionar um arquivo, pressione a tecla Shift ou Ctrl e, em seguida, selecione outro), em seguida, com o botão direito e selecione Compare Performance Reports.

Um relatório de comparação é exibida, conforme mostrado no do Figura 10. No aplicativo de exemplo, você pode ver o número de Contentions completa da função MatMult descartada do 1,003 como 0.

A Figura 10 do relatório de comparação

Métodos de coleta de dados alternativo

Se você criar a sua sessão de desempenho para amostragem ou instrumentação de perfilação, você pode sempre convertê-lo mais tarde para o modo de concorrência. Uma maneira de fazê-lo rapidamente é usar o menu de modo de criação de perfil no Performance Explorer. Basta selecionar o modo que você gostaria de estar no e você é bom ir.

Você também pode ir através da configuração de propriedades da sessão. Aponte para a sua sessão no Performance Explorer, clique com o botão direito para exibir o menu de contexto e selecione Propriedades. Na guia geral de páginas de propriedades permite que você controle o modo de sessão de criação de perfil e outros parâmetros de criação de perfil.

Depois que o modo de criação de perfil é definido para simultaneidade (ou em amostragem, no caso), é possível o lançamento de seu aplicativo (ele já está na sua lista de destinos se você usou o Performance Wizard, ou você pode adicioná-lo lá manualmente) ou você pode anexar a um aplicativo que está em execução. Explorer de desempenho oferece os controles para executar essas tarefas, como do Figura 11 mostra.

De criação de perfil de controles de Performance Explorer, a Figura 11

A interface do usuário do Studio Visual automatiza a um número de etapas necessárias para coletar dados de perfil. No entanto, é possível coletar dados de perfil usando ferramentas de linha de comando, que podem ser útil para execuções automatizadas e scripts.

Para iniciar o aplicativo no modo de criação de perfil de contenção, abra o prompt de comando do Visual Studio (o que coloca todos os binários do gerador de perfil no seu caminho, o x86 ou x64 ferramentas) e, em seguida, faça o seguinte:

1. VSPerfCmd.exe /start:CONCURRENCY, RESOURCEONLY /output: <YourOutputFile>

2. VSPerfCmd.exe /launch: < Your Application > /args: “ < Your Application argumentos > ”

3. Execute seu cenário.

4. VSPerfCmd.exe / desconectar

   • Essa etapa não é necessária se seu aplicativo é encerrado, mas isso faz com que nenhum dano para que você pode adicioná-lo para seus scripts.

5. VSPerfCmd.exe /shutdown

   Agora você pode abrir YourOutputFile.VSP no Visual Studio para análise.

Se você tiver um aplicativo que está sendo executado já, você pode anexar o gerador de perfil para ela usando essas etapas:

1. VSPerfCmd.exe /start:CONCURRENCY, RESOURCEONLY /output: <YourOutputFile>
2. VSPerfCmd.exe / conexão: < nome de processo ou PID >
3. Execute seu cenário.
4. VSPerfCmd.exe / desconectar
5. VSPerfCmd.exe /shutdown

Uma explicação mais detalhada das opções de linha de comando disponíveis pode ser encontrada no msdn.microsoft.com/library/bb385768(VS.100) de .

Uma variedade de modos de exibição do Visual Studio permitem que você inspecione detalhadamente os dados coletados. Alguns modos de exibição oferecem uma imagem de tempo de vida do aplicativo no todo, enquanto outras pessoas se concentrar em contentions específicas — usá-los, você encontrará mais valiosos.

Ao analisar os resultados da criação de perfil, você pode usar transições de um modo de exibição para outro através de hiperlinks, clica duas vezes ou menus de contexto, ou você pode alternar diretamente para qualquer modo de exibição disponível por meio de um drop-down menu. A Figura 12 descreve resumidamente cada um dos modos de exibição.

A Figura 12 do exibições de análise

A contenção de recursos novos recursos do Visual Studio para criação de perfil deve ajudá-lo a descobrir problemas de desempenho, usando a sincronização de segmentos no código e permitem que você melhore seu tempo de execução do aplicativo por meio da alteração, reduzir ou eliminar sincronização desnecessária.

Maxim Goldin é engenheiro de design de software sênior na Microsoft. Ele trabalhou na equipe de engenharia do Visual Studio desde 2003. Pode ser contatado de mgoldin@microsoft.com e blogs de a de blogs.msdn.com/b/mgoldin.

Para obter informações adicionais sobre fluxos de investigação de desempenho Consulte a postagem no blogs.msdn.com/b/mgoldin/archive/2010/04/22/resource-contention-concurrency-profiling-in-visual-studio-2010-performance-investigation-flows.aspx de do meu blog complementar.

Graças aos seguintes especialistas técnicos para revisar este artigo: Steve Carroll, Anna Galaeva, Daryush Laqab, Marc Popkin-Paine, Chris Schmich e Colin Thomsen