Il presente articolo è stato tradotto automaticamente.

Prestazioni dei thread

Resource Contention Concurrency Profiling in Visual Studio 2010

Maxim Goldin

Come processori multicore diventano sempre più frequenti, gli sviluppatori di software siano creando applicazioni multithread che sfruttano la capacità di elaborazione aggiuntivo per ottenere migliori prestazioni. Grazie all'utilizzo di thread paralleli, è possibile suddividere il lavoro in più attività complessivo e tali attività vengono eseguite in parallelo.

Thread, tuttavia, spesso è necessario comunicare tra loro per completare un'attività, a volte necessario sincronizzarne il comportamento se è necessario un algoritmo o dati di accesso. Ad esempio, è necessario concedere accesso in scrittura contemporaneamente agli stessi dati ai thread in modalità si escludono a vicenda per evitare il danneggiamento dei dati.

Sincronizzazione avviene spesso tramite l'utilizzo di oggetti di sincronizzazione condiviso, in cui il thread acquisisce l'oggetto viene concesso l'accesso condiviso o esclusivo codice sensibili ai dati. Quando non è necessario accedere, il thread abbandona la proprietà e altri thread possono tentare di ottenere un accesso. A seconda del tipo di sincronizzazione utilizzato, richieste simultanee per la proprietà potrebbero consentire di accedere alle risorse condivise in contemporanea di più thread o alcuni dei thread potrebbe essere bloccata fino a quando l'oggetto viene rilasciato dall'acquisizione precedente. Esempi 
include sezioni critiche in C/C ++ che utilizzano le routine di accesso EnterCriticalSection e LeaveCriticalSection, la funzione WaitForSingleObject in C/C ++ e l'istruzione lock e la classe Monitor in C#.

La scelta del meccanismo di sincronizzazione deve essere eseguita con cautela, poiché non corretta sincronizzazione tra thread può ridurre anziché di migliorare l'incremento delle prestazioni è l'obiettivo del multithreading. Di conseguenza, è sempre più importante essere in grado di individuare le situazioni in cui i thread sono bloccati a causa di blocco contentions che Nessun corso.

Gli strumenti di prestazioni di Visual Studio 2010 includono un nuovo metodo di analisi, analisi contesa di risorse, che consente di rilevare i conflitti di concorrenza tra i thread. È possibile trovare grande prima esaminare questa funzionalità nel post del blog di Wintellect ’ John Robbins per wintellect.com/CS/blogs/jrobbins/archive/2009/10/19/vs-2010-beta-2-concurrency-resource-profiling-in-depth-first-look.aspx .

In questo articolo è possibile scorrere un'indagine contesa di profiling e spiegare i dati possono essere raccolti mediante l'IDE di Visual Studio 2010 e strumenti della riga di comando. Verrà inoltre spiegato come analizzare i dati in Visual Studio 2010 e verrà illustrato come spostare dalla visualizzazione uno analisi a altro durante la realizzazione dell'indagine contesa. Verrà quindi correggere il codice e il confronto analisi risultati dell'applicazione modificata con l'originale profiling per convalidare la correzione consente di ridurre il numero di contentions.

Iniziare con il problema

Ad esempio, si utilizzerà la stessa applicazione di moltiplicazione di matrice Hazim Shafi utilizzato nel suo post di blog “ Performance motivo 1: Identificazione di conflitto di blocco ” (blogs.msdn.com/hshafi/archive/2009/06/19/performance-pattern-1-identifying-lock-contention.aspx). Nell'esempio di codice è scritto in c ++, ma i concetti che tratterò sono ugualmente applicabili al codice gestito.

L'applicazione di esempio di matrice di moltiplicazione diversi thread viene utilizzato per moltiplicare due matrici. Ogni thread ottiene una parte del processo e verrà eseguito il seguente frammento di codice:

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);
}

Ogni thread dispone di un proprio ID (myid) ed è responsabile per il calcolo del numero di righe (uno o più) nella matrice risultante C utilizzando matrici A e B come input. Ispezione del codice di chiusura indica che nessuna operazione di scrittura-condivisione veramente ambiguo accade e scrive ogni thread su un'altra riga di c. Ancora lo sviluppatore ha deciso di impedire l'assegnazione alla matrice con una sezione critica. Grazie allo sviluppatore, come offre mi consente di illustrare i nuovi strumenti di prestazioni di Visual Studio 2010 per trovare con facilità la sincronizzazione ridondante.

Raccolta dati di profilo

Se si dispone di un progetto di Visual Studio con il codice illustrato in precedenza (anche se non obbligatorio, è possibile collegare il profiler a qualsiasi applicazione che è già in esecuzione), avviare la contesa di analisi facendo clic su Avvia Creazione guidata prestazioni dal menu Analizza.

Nella prima pagina della procedura guidata, illustrata in di Figura 1, scegliere la concorrenza e assicurarsi che sia selezionata l'opzione “ raccogliere dati di contesa di risorse ”. Si noti che concorrenza di contesa di risorse profiling funziona su qualsiasi versione del sistema operativo Windows. L'opzione “ visualizzare il comportamento di un'applicazione multithread ” richiede Windows Vista o Windows 7.

Figura 1 profiling attivazione concorrenza Resource

Nella seconda pagina della procedura guidata, verificare che sia destinato al progetto corrente. Nell'ultima pagina della procedura guidata, assicurarsi che sia selezionata l'opzione “ Avvia analisi al termine della procedura guidata ”, quindi fare clic su Fine. Avvio dell'applicazione in esecuzione con il profiler. Quando chiude, il file di dati di analisi vengono visualizzate nella finestra Esplora prestazioni (vedere di Figura 2).

Figura 2 prestazioni analisi file risultati in Esplora prestazioni

Il rapporto di analisi viene aperto in Visual Studio automaticamente e visualizza i risultati di analisi delle prestazioni della visualizzazione riepilogo, illustrato in di Figura 3.

Figura 3 di visualizzazione Riepilogo del report di profiling

Analisi dei dati di profilo

Sincronizzazione non provoca conflitti di blocco. Se è disponibile un blocco, un tentativo di diventare un proprietario del blocco non blocca il thread di esecuzione e si verifica alcun conflitto. In modalità di analisi di contesa di risorse, il profiler raccoglie i dati solo per gli eventi di sincronizzazione che causano conflitti e non segnala le acquisizioni di risorse riusciti (sbloccare). Se l'applicazione non causa alcun contentions, i dati non verranno raccolti. Se si ottengono dati, significa che l'applicazione dispone di blocco contentions.

Per ogni conflitto, i report profiler quale thread è stato bloccato, dove la contesa durante (stack di chiamate e risorsa), quando la contesa (timestamp) si è verificato e la quantità di tempo che il thread è stato bloccato il tentativo di acquisire un blocco (lunghezza) immettere una sezione critica, attendere per un singolo oggetto e così via.

Quando si apre il file, si vedrà prima della visualizzazione Riepilogo ( di Figura 3), con tre aree principali, che è possibile utilizzare per la diagnostica breve:

1. Il grafico contentions indica il numero di contentions secondo tracciato per tutta la durata dell'applicazione. Visivamente può esaminare i picchi di conflitto o selezionare un intervallo di tempo e uno zoom in esso o filtrare i risultati. Filtro re-analyzes dati e rimuove i dati all'esterno dell'intervallo selezionato.
2. La tabella più risorse Contended Elenca le risorse che causato contentions più rilevato.
3. La tabella più thread Contended Elenca i thread con il numero più alto di contentions. Questa tabella utilizza il numero di contentions come criterio, non la lunghezza della contentions. Pertanto, potrebbe essere un thread bloccato in una singola contesa per lungo tempo, ma non verranno visualizzato nella visualizzazione riepilogo. D'altro canto, un thread ha molti contentions molto breve, con ogni conflitto di bloccare il thread per solo tempi molto brevi, dovrebbe essere presentato nella visualizzazione riepilogo.

In presenza di una risorsa che è responsabile della maggior parte dei contentions esaminare tale risorsa in maggiore dettaglio. Se si notano un thread che si verifica un numero elevato di contentions che non previsto, esaminare contentions del thread.

Ad esempio, in di Figura 3, è possibile visualizzare che 1 sezione critica è responsabile di quasi tutti i contentions (99.90%) in tale applicazione. Let’s esaminare attentamente tale risorsa.

I nomi delle risorse e thread ID nella visualizzazione riepilogo sono collegamenti ipertestuali. Fare clic su sezione critica 1 trasferimenti di dettagli risorse visualizzare (vedere di Figura 4), in cui è impostato il contesto per la risorsa specifica, ovvero 1 sezione critica.

Figura 4 di visualizzazione dettagli risorse

Dettagli risorsa

Nella parte superiore della visualizzazione dettagli di risorse viene visualizzato un grafico basato sull'ora in cui ogni riga orizzontale appartiene a un thread. Le righe sono contrassegnate dalla funzione thread principale, a meno che il nome del thread gestito nel codice (ad esempio, utilizzando la proprietà C# System.Threading.Thread.Name). Un blocco in questa riga rappresenta un conflitto del thread sulla risorsa. La lunghezza del blocco è la lunghezza della contesa. Blocchi di righe differenti potrebbero sovrapporsi nel tempo, ovvero più thread bloccati sulla risorsa contemporaneamente.

La riga totale è speciale. Non appartiene a un thread specifico, ma contiene tutti i contentions di tutti i thread in questa risorsa (è effettivamente una proiezione di contesa dei blocchi di riga). Come si può vedere, sezione critica 1 era molto occupato, non sembra avere qualsiasi slot vuoto su una riga totale.

È possibile ingrandire in una parte specifica del grafico selezionando un intervallo di tempo utilizzando il pulsante sinistro del mouse (sinistro nel punto di grafico che si desidera avviare e quindi trascinare il puntatore verso destra). Esistono due collegamenti nella parte superiore destra del grafico, Zoom reimpostare e zoom indietro. Reimpostazione di Zoom consente di ripristinare la visualizzazione del grafico originale. Lo zoom viene che nuovamente procedura dal passaggio un-zooming grafico nello stesso modo in cui che è ingrandita.

Il modello generale di contesa tra blocchi potrebbe portare a conclusioni sull'esecuzione dell'applicazione. Ad esempio, si noterà che contentions dei vari thread sono molto sovrapposte nel tempo, suggerisce al minore parallelizzazione ottimale. Ogni thread è bloccato sulla risorsa molto più a lungo è in esecuzione ed è ancora un'altra indicazione di svantaggi dell'applicazione.

Dettagli funzione

Nella parte inferiore della visualizzazione dettagli di risorse è uno stack di chiamate contesa, i dati non viene visualizzati finché non si seleziona un conflitto specifico. Quando si seleziona un blocco, il corrispondente stack visualizzato nel Pannello inferiore. Può anche posizionare su un blocco di contese sul grafico senza fare clic su di esso e una finestra popup consentirà di stack e la lunghezza di contesa.

Come si vede nello stack di chiamate contesa, una delle funzioni app esempio chiamato MatMult è elencato, in modo da sapere che era causato il conflitto. Per determinare quale riga del codice di funzione è responsabile per la contesa, fare doppio clic sul nome della funzione nel Pannello stack di chiamata. Che consente la visualizzazione dettagli Function, in di Figura 5.

Figura 5 di visualizzazione dettagli funzione

In questa visualizzazione è possibile visualizzare una rappresentazione grafica delle funzioni che hanno chiamato MatMult, nonché le funzioni chiamate all'interno di esso. Nella sezione inferiore della visualizzazione mostra chiaramente che EnterCriticalSection(&mmlock) è responsabile il thread bloccato l'ora.

Quando si è certi di quale riga del codice è responsabile di contentions, si potrebbe valutare la decisione di implementare la sincronizzazione in questo modo. È il modo migliore per proteggere il codice? È affatto protezione richiesto?

Nell'applicazione di esempio utilizza una sezione critica in questo codice è necessario perché il thread non condividono scritture per le righe matrice stessa. Gli strumenti di prestazioni di Visual Studio consente di portare il punto in cui può commentare l'utilizzo di mmlock, velocizzando significativamente l'applicazione. Se solo fosse sempre facile!

Per una descrizione più approfondita della visualizzazione dettagli di funzione, vedere il blog del team di Visual Studio Profiler in blogs.msdn.com/profiler/archive/2010/01/19/vs2010-investigating-a-sample-profiling-report-function-details.aspx .

Dettagli del thread

Come accennato in precedenza, visualizzazione Riepilogo fornisce un buon punto di partenza per l'indagine. Esaminando le tabelle più thread Contended e Contended più risorse, è possibile decidere come procedere. Se si riscontra che uno dei thread sembrano sospetto perché non previsto per essere incluso nell'elenco dei thread contended superiore, è possibile dare uno sguardo al thread.

Selezionare l'ID del thread nella visualizzazione Riepilogo per passare ai dettagli thread visualizzare (vedere di Figura 6). Sebbene questa visualizzazione è simile alla visualizzazione dettagli Resource, ha un significato diverso perché Visualizza contentions nel contesto del thread selezionato. Ogni linea orizzontale rappresenta una risorsa che il thread era contesa per tutta la durata del thread. In questo grafico sarà visibile la contesa tra blocchi sovrapposti in tempo dato che implica che lo stesso thread bloccato su più risorse contemporaneamente.

Figura 6 Thread Details View con blocco conflitto selezionato

Si noti che WaitForMultipleObjects (che non sono visualizzati qui) viene gestita separatamente e viene rappresentato con una linea singola grafico per l'insieme di oggetti. Infatti, il profiler gestisce tutti gli oggetti parametro di WaitForMultipleObjects come una singola entità.

Manipolazione di che procedere nella visualizzazione dettagli di risorse (ingrandimento e riduzione del grafico, selezionando specifiche contentions e visualizzare la durata in millisecondi e lo stack della chiamata) sono applicabili anche alla visualizzazione Dettagli Thread. Fare doppio clic sul nome della funzione nel Pannello Stack di chiamate contesa per passare alla visualizzazione dettagli funzione di tale funzione.

Nell'esempio si può vedere che il thread impiega più tempo rispetto all'esecuzione nella parte iniziale dell'esecuzione del blocco e quindi viene bloccata da molto tempo su una serie di più handle. Come ultimo blocco è causato da in attesa del completamento di altri thread, contentions anticipata indicare utilizzo di thread non ottimale, causando il thread in uno stato bloccato più in uno stato in esecuzione.

Ricerca dei giù del problema

Come si può notare, le etichette degli assi del grafico sono collegamenti ipertestuali. Consente di passare da una visualizzazione dettagliata delle risorse e thread, impostare il contesto necessario per la visualizzazione ogni volta. Ciò può risultare utile in un approccio iterativo per individuare e risolvere un problema. Ad esempio, è possibile controllare la risorsa R1 bloccati molti thread. È possibile passare dai dettagli risorse visualizzare una visualizzazione dettagliata di thread T1 e scoprire che esso è stato bloccato non solo di R1, ma a volte anche sulla risorsa R2. È quindi possibile approfondire i dettagli di R2 e osservare tutti i thread che sono stati bloccati da R2. È possibile fare clic sull'etichetta del thread T2 che disegna l'attenzione per verificare tutte le risorse bloccate T2, successivo e così via.

Conflitti dei dati di profilo non fornisce un'esplicita risposta alla domanda di chi detiene un blocco alla volta. Ma dato notevole utilizzo dell'oggetto di sincronizzazione tra thread e la conoscenza del comportamento dell'applicazione, è possibile identificare il proprietario di un blocco (un thread ha avuto esito positivo nell'acquisizione di blocchi di sincronizzazione) dal calcolo pivot dei dati dalla risorsa dettagli Dettagli thread e il backup.

Si supponga, ad esempio, nella visualizzazione Dettagli Thread che è visualizzato un thread T viene bloccato sulla risorsa R a t ora. È possibile passare alla visualizzazione dettagli risorse di R facendo clic sull'etichetta R e visualizzare tutti i thread bloccati di R durante la durata dell'applicazione. A t ora si vedrà un numero di essi (ad esempio T) bloccato su r. Un thread non bloccato su R a t ora è titolare di un blocco.

Accennato che riga totale del grafico è una proiezione di tutti i blocchi di contesa. L'etichetta totale è un collegamento ipertestuale, ma dalla visualizzazione dettagli risorse che è necessario per il conflitto visualizzare (vedere di Figura 7), che è un insieme di strutture di chiamata contesa per ogni risorsa. Il percorso della struttura delle chiamate di risorse appropriata a caldo viene attivato automaticamente. Questa visualizzazione mostra statistiche tempo di blocco per ogni risorsa e per ogni nodo (funzione) e contentions nella struttura delle chiamate di risorse. A differenza delle altre visualizzazioni, questo aggrega stack contesa per struttura di chiamata delle risorse come nelle altre modalità di analisi e fornisce statistiche per l'intera esecuzione dell'applicazione.

Figura 7 visualizzazione conflitto con percorso ricorrente applicato alla sezione critica 1

Dalla visualizzazione conflitto è possibile tornare alla visualizzazione dettagli risorse di qualsiasi risorsa utilizzando il menu di scelta rapida. Scegliere una risorsa, destro del mouse e selezionare Dettagli conflitto Resource. Altre azioni interessanti sono inoltre disponibili nel menu di scelta rapida. Un suggerimento generale, esplorare i menu di scelta rapida nelle visualizzazioni di Profiler, può essere molto utile!

Scegliere l'etichetta totale della visualizzazione Dettagli Thread per visualizzare la visualizzazione dei processi, in cui il thread è selezionato (vedere di Figura 8). In questa visualizzazione che è possibile visualizzare quando il thread è stato avviato relativo per l'ora di avvio dell'applicazione, quando è stato terminato, la durata è stata eseguita, quanti contentions esperti e quanto tempo è stato bloccato in tutti contentions (in millisecondi e in percentuale della durata del thread).

Figura 8 di visualizzazione processi

Di nuovo, è possibile tornare alla visualizzazione Dettagli Thread per qualsiasi thread utilizzando il menu di scelta rapida, selezionare un thread di interesse, fare clic destro e scegliere Mostra dettagli conflitto di thread.

Un altro flusso di indagine possibili, è possibile visualizzare direttamente la visualizzazione processi quando il file viene aperto, ordinare i thread facendo clic sul titolo di una delle colonne disponibili (ad esempio, ordinamento thread per il numero di contentions), selezionare uno dei thread e quindi passare al grafico di dettagli conflitto del thread tramite il menu di scelta rapida.

Correggere il problema e confronta risultati

Dopo aver individuato la causa principale di contentions il blocco dell'applicazione, è possibile impostare come commento la sezione critica mmlock e rieseguire il profiling:

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);
}

Previsto numero di contentions per ridurre e in realtà profiling del codice modificato rapporti solo conflitti di blocco, come illustrato in di Figura 9.

Figura 9 di visualizzazione Riepilogo dei risultati di profiling del codice corretto

È inoltre possibile confrontare i risultati delle prestazioni di nuove e precedenti di Visual Studio. A tale scopo, selezionare entrambi i file in Esplora prestazioni (selezionare un file, premere MAIUSC o Ctrl e quindi selezionare un altro), quindi fare clic destro e scegliere Confronta report di prestazioni.

Viene visualizzato un rapporto di confronto, come illustrato in di Figura 10. Nell'applicazione di esempio, è possibile visualizzare il numero di conflitti inclusivo della funzione MatMult eliminata da 1,003 su 0.

Figura 10 di Rapporto confronto

Metodi di raccolta di dati alternativo

Se si crea la sessione di prestazioni per campionamento o Strumentazione di analisi, si può sempre convertirlo in seguito alla modalità di concorrenza. Un modo per eseguire rapidamente consiste nell'utilizzare il menu modalità profiling in Esplora prestazioni. È sufficiente selezionare la modalità desiderata in e si è buona norma passare.

È possibile accedere tramite l'impostazione di proprietà della sessione. Scegliere la sessione in Esplora prestazioni, fare clic per visualizzare il menu di scelta rapida, quindi scegliere Proprietà. Scheda Generale della finestra pagine delle proprietà consente di controllare la modalità di sessione di profiling e altri parametri di analisi.

Dopo aver impostata la modalità di analisi della concorrenza o campionamento Parimenti, è possibile l'avvio dell'applicazione (è già nell'elenco delle destinazioni se si utilizza Creazione guidata prestazioni oppure è possibile aggiungerlo vi manualmente) oppure è possibile allegare a un'applicazione che sia in esecuzione. Esplora prestazioni fornisce i controlli per eseguire queste operazioni, come di Figura 11.

Figura 11 profiling controlli di Esplora prestazioni

Interfaccia utente di Visual Studio consente di automatizzare numerose operazioni necessarie per raccogliere dati di analisi. Tuttavia, è possibile raccogliere i dati di analisi utilizzando gli strumenti della riga di comando, possono essere utili per l'esecuzione automatiche e script.

Per avviare l'applicazione in conflitto in modalità di analisi, aprire il prompt dei comandi di Visual Studio (che inserisce tutti i file binari di profiler nel percorso, entrambi x 86 o x64 strumenti) e quindi eseguire le operazioni seguenti:

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

2. /Launch VSPerfCmd.exe: /args < applicazione >: “ < Your Application argomenti > ”

3. Esecuzione dello scenario

4. VSPerfCmd.exe / disconnessione

   • Questo passaggio non è obbligatorio se Termina applicazione, ma è possibile aggiungere script non causa alcun danno.

5. VSPerfCmd.exe /shutdown

   È quindi possibile aprire YourOutputFile.VSP in Visual Studio per l'analisi.

Se si dispone di un'applicazione in cui è già installato, è possibile collegare il profiler utilizzando la procedura:

1. VSPerfCmd.exe /start:CONCURRENCY, RESOURCEONLY /output: <YourOutputFile>
2. VSPerfCmd.exe / allegare: < PID o nome processo >
3. Esecuzione dello scenario
4. VSPerfCmd.exe / disconnessione
5. VSPerfCmd.exe /shutdown

Una spiegazione più dettagliata delle opzioni della riga di comando disponibili, visitare msdn.microsoft.com/library/bb385768(VS.100) .

Numerose visualizzazioni di Visual Studio consentono di esaminare attentamente i dati raccolti. Alcune visualizzazioni di fornire una panoramica della durata dell'applicazione nel suo complesso, mentre altri concentrarsi su contentions specifico, utilizzare quelli disponibili più preziosi.

Quando si analizzano i risultati dell'analisi, è possibile utilizzare le transizioni da una visualizzazione a altra tramite collegamenti ipertestuali, doppio clic o menu di scelta rapida oppure è possibile passare direttamente a qualsiasi visualizzazione disponibile attraverso un rilascio-menu. Figura 12 viene descritta brevemente ciascuna delle visualizzazioni.

Figura 12 di visualizzazioni analisi

Visualizzazione	Descrizione
Riepilogo	Informazioni di riepilogo viene presentate come punto di partenza per l'indagine. Si tratta della prima visualizzazione che viene visualizzato e si apre automaticamente dopo una sessione di analisi è posizionato e il file dei risultati è pronto.
Chiamare Tree	Una struttura di chiamata aggregata di tutti gli stack di contesa. Qui è possibile visualizzare gli stack sono stati responsabili di contentions.
Moduli	Elenco dei moduli che contengono funzioni, ogni causando un conflitto. Ogni modulo dispone di un elenco di funzioni pertinenti e il numero di contentions rilevato.
Chiamante/chiamato	Una visualizzazione a tre facciate che presenta funzione F, tutte le funzioni che chiamano F e funzioni che vengono chiamate da F (solo chiamate comportato contentions, ovviamente).
Funzioni	Un elenco di tutte le funzioni rilevate qualsiasi stack di conflitti di dati associati.
Righe	Le righe della funzione nel codice sorgente.
Dettagli risorsa	Dettagli relativi a una risorsa specifico (ad esempio, un blocco), che mostra tutti i thread bloccati su di esso durante il ciclo di vita dell'applicazione.
Dettagli del thread	Informazioni dettagliate su un thread specifico, contenente tutte le risorse (ad esempio i blocchi) il thread bloccato su.
Conflitto	Simile alla struttura di chiamata, ma qui chiamata strutture separate per ogni conflitto di risorse. In altre parole, questa visualizzazione presenta un insieme di strutture di chiamata, ogni stack contenente bloccati su una risorsa specifica.
Segni	Un elenco di indicatori registrati automaticamente e manualmente, dove ogni Mark è associato il timestamp e i valori dei contatori di Windows.
Processi	Elenco di processi esaminati, dove ogni processo dispone di un elenco dei thread e ciascun thread è attribuito il numero di contentions che verificato e il riepilogo durata bloccati.
Dettagli funzione	Dettagli su una funzione specifica, incluse le funzioni, chiamate e i dati raccolti.
IPs	Una lista di puntatori istruzione in cui si è verificata contesa (Beh, un elenco delle funzioni come EnterCriticalSection, WaitForSingleObject e così via, trattandosi in cui accade effettivamente contesa).

La contesa di risorse nuova analisi funzionalità di Visual Studio consente di individuare problemi di prestazioni mediante la sincronizzazione dei thread nel codice e consentono di migliorare il runtime dell'applicazione modificando, riducendo o eliminando sincronizzazione non necessari.

Maxim Goldin è un ingegnere di progettazione senior software Microsoft. Ha lavorato nel team di Visual Studio Engineering rispetto a 2003. Contattarlo all' mgoldin@microsoft.com e blog ha in blogs.msdn.com/b/mgoldin.

Per ulteriori informazioni sui flussi di analisi delle prestazioni vedere complementare blog post in blogs.msdn.com/b/mgoldin/archive/2010/04/22/resource-contention-concurrency-profiling-in-visual-studio-2010-performance-investigation-flows.aspx.

Grazie ai seguenti esperti tecnici per la revisione di questo articolo: Steve Carroll, Anna Galaeva, Daryush Laqab, Marc Popkin-Paine, Chris Schmich e Colin Thomsen