Herramienta de análisis C # / .NET para encontrar condiciones de carrera / puntos muertos

¿Hay alguna herramienta que analice el código .NET y encuentre las condiciones de carrera?

Tengo un poco de código que tiene una propiedad pública estática que obtiene o crea un campo estático privado. También tiene un método público estático que establece este campo como nulo (… ¡sí, lo sé! …)

Como no existen lockings en ninguno de estos métodos, es una apuesta segura que las cosas irán terriblemente mal en el futuro. Necesito una herramienta que recursivamente vaya a través de cosas que llaman a cualquiera de estos métodos y ver si algo se generó en otro hilo.

Estoy buscando una herramienta o quizás una secuencia de comandos nDepend SQL (si esto es posible).

    Probablemente estés buscando uno de estos:

    • AJEDREZ
    • Typemock Racer

    NOTA : Esta respuesta es de 2010. Al igual que con todas las recomendaciones, las recomendaciones tienden a cambiar con el tiempo. Ahora puede haber otros productos, CHESS, que era un proyecto de Microsoft Research Labs, puede haber evolucionado hasta convertirse en un producto final o haber sido eliminado por completo. Por favor, tome esta respuesta con un grano de sal y realice una nueva investigación sobre qué productos son adecuados ahora.

    Jinx hará esto en tiempo de ejecución (no estáticamente) pero puede valer la pena mirarlo.

    Es posible que desee verificar CHESS .

    Vea las respuestas aquí: ¿Qué herramientas de análisis estático están disponibles para C #?

    Algunas herramientas de análisis estático pueden hacer la detección de punto muerto.

    Además, prueba FxCop de Microsoft.

    He estado experimentando sobre cómo rastrear fácilmente esos. He estado trabajando para rastrear algunos lockings, especialmente en escenarios donde se usan muchas declaraciones de locking diferentes.

    Mi objective es detectar interlockings antes de que sucedan, por ejemplo, si tienes dos recursos, sabes que siempre debes usarlos en el mismo orden, de lo contrario podría producirse un punto muerto.

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

    … en otro lugar en la aplicación …

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

    En este caso estoy usando lockObj1 luego lockObj2 en un lugar y usándolos en el orden opuesto en otro lugar, esto es algo que te gustaría evitar en una aplicación. Por supuesto, las instrucciones de locking no necesitan ser usadas una después del otros como en el ejemplo, su aplicación compleja podría tener varios objetos complejos que interactúan entre sí

    He cargado el código con los casos de prueba aquí https://github.com/glmnet/LockTracer

    ¿Has mirado ants de puerta roja ? No estoy seguro de si hará todo lo que necesita, pero es un buen producto para:

    • Identificar cuellos de botella de rendimiento en minutos
    • Optimizar el rendimiento de la aplicación .NET
    • Desplázate hacia líneas lentas de código con tiempos de línea
    • Perfil aspx, ASP.NET, código C # y aplicaciones VB.NET