Reglas para encontrar / evitar datos compartidos en una aplicación multiproceso

Question

Hy,

como todos sabemos, desarrollar una aplicación de multiproceso es una tarea difícil. Especialmente el punto cuándo y qué bloquear no es tan obvio IMHO. A menudo estoy viendo un método / clase y debo preguntarme si comparto algunos datos, que pueden ser modificados por múltiples hilos. Y cuando no estoy seguro de que termine en un bloqueo () sobre un bloque de código completo.

Entonces, lo que me gusta saber: ¿Tiene sugerencias para patrones / reglas, etc. para identificar datos compartidos? O técnicas para garantizar que su código sea seguro para subprocesos.

Por ejemplo:

• Los métodos estáticos no deberían modificar los campos de clase. (A menos que bloqueen el campo.)
  
• Los parámetros de referencia de un método no deben pasarse " directamente " ;. Siempre pasa un clon.

Por cierto:

Microsoft Research está trabajando en CHESS . Una herramienta para encontrar y reproducir Heisenbugs en programas concurrentes. Espero que esto y PLINQ mejoren el desarrollo de programas concurrentes.

Answer 1

Siempre que sea posible, haga que sus tipos sean inmutables para empezar. Entonces no hay necesidad de clonar. Si necesita " cambiar " el contenido de un objeto, hace que el método devuelva un nuevo objeto en su lugar, al igual que String.Replace etc.

Este es básicamente el estilo de programación funcional, y es encantador. Es lamentable que no (actualmente) tengamos colecciones inmutables integradas en el marco .NET, aunque hay otras de terceros, incluido uno de nuestro propio JaredPar .

Answer 2

La encapsulación de datos en una clase es útil cuando se hace seguro para subprocesos. Puede controlar cómo se accede a los datos y puede hacer que la clase sea responsable de la sincronización, en lugar de tener un código en toda la aplicación que intenta sincronizarse correctamente.

Además, tiene un lugar donde colocar una variable privada que puede usar como identificador de bloqueo, de modo que puede evitar usar los datos en sí como identificador del bloqueo. Al tener una variable privada dedicada como identificador de bloqueo, elimina una posible fuente de interbloqueos.