C# /. NET strumento di analisi per trovare condizioni di gara/deadlock

Question

C'è uno strumento che analizza il codice .NET e trova condizioni di gara?

Ho un po 'di codice che ha una proprietà statica pubblica che ottiene o crea un campo statico privato. Ha anche un metodo statico pubblico che imposta questo campo su null (... sì, lo so! ..)

Poiché non ci sono blocchi attorno a nessuno di questi metodi, è una scommessa sicura che le cose andranno orribilmente sbagliato in futuro. Ho bisogno di uno strumento che ricorsivamente passerà attraverso le cose che chiamano uno di questi metodi e vedere se qualcosa è stato generato su un altro thread.

Sto cercando uno strumento o uno script SQL nDepend (se possibile).

Answer 1

Probabilmente siete alla ricerca di uno di questi:

• CHESS
• Typemock Racer

---

NOTA: Questa risposta è dal 2010. Come per tutte le raccomandazioni risposte, le raccomandazioni tendono a cambiare nel tempo. Potrebbero esserci altri prodotti là fuori ora, CHESS, che era un progetto di Microsoft Research Labs potrebbe essersi evoluto in un prodotto finale o essere stato completamente demolito. Si prega di prendere questa risposta con un pizzico di sale e condurre nuove ricerche su quali prodotti sono adatti ora.

Answer 2

Si potrebbe voler controllare CHESS.

Answer 3

Jinx lo eseguirà in fase di esecuzione (non in modo statico) ma potrebbe valerne la pena.

Answer 4

Hai guardato Red-Gate Ants? Non sono sicuro se lo farà tutto il necessario, ma è un buon prodotto per:

• identificare i colli di bottiglia delle prestazioni in pochi minuti
• Ottimizzare le prestazioni delle applicazioni .NET
• Drill-down per rallentare righe di codice con temporizzazioni a livello di linea
• Profilo aspx, ASP.NET, C# codice, e VB.NET applicazioni

Answer 5

Vedi le risposte qui: What static analysis tools are available for C#?

Alcuni strumenti di analisi statici possono eseguire il rilevamento di deadlock.

Inoltre, provare FxCop da Microsoft.

Answer 6

Ho sperimentato su come tracciare facilmente quelli. Ho lavorato per tenere traccia di alcuni deadlock, specialmente su scenari in cui vengono utilizzate molte istruzioni di blocco diverse.

Il mio obiettivo è rilevare i deadlock prima che si verifichino, ad es. se hai due risorse, sai che devi sempre usarle nello stesso ordine, altrimenti si verificherà un deadlock .

lock (lockObj1) 
lock (lockObj2) 
{ 
    // some code 
} 

...da qualche altra parte in app ...

lock (lockObj2) 
lock (lockObj1) // <- I expect some "possible deadlock" detection here 
{ 
    // some code 
} 

In questo caso sto usando lockObj1 poi lockObj2 in un luogo e utilizzando nell'ordine opposto in un altro luogo, questo è qualcosa che ti piacerà di evitare in un'applicazione Naturalmente, le dichiarazioni di blocco non è necessario per essere utilizzato uno dopo l'altro come nell'esempio, l'applicazione complesso potrebbe avere diversi oggetti complessi che interagiscono tra loro

ho caricato il codice con i casi di test qui https://github.com/glmnet/LockTracer