c# - net - ¿Qué características hacen que una clase sea segura para subprocesos?
thread vb net (6)
¿Hay algún estándar, recomendación o guía para la programación de seguridad de subprocesos?
El estándar más importante es garantizar que todos los miembros estáticos sean seguros para subprocesos. Verá que todas las API bien escritas, incluida la biblioteca de clases base .NET, hacen que esta garantía sea general. Hay una muy buena razón para esto. Dado que los miembros estáticos se comparten a través de un dominio de aplicación, pueden ser utilizados por muchos subprocesos diferentes sin que te des cuenta. Sería incómodo en el mejor de los casos proporcionar su propia sincronización para cada acceso de miembro estático. Imagina cómo sería si Console.WriteLine no fuera seguro para subprocesos.
En cuanto a las recomendaciones y pautas, hay muchos patrones bien establecidos para realizar la programación concurrente. Los patrones que hay por ahí cubren una amplia variedad de problemas de programación y utilizan muchos mecanismos de sincronización diferentes. El patrón productor-consumidor es uno de los muchos patrones bien conocidos que resuelven un gran porcentaje de problemas de programación concurrentes.
Leer subprocesos en C # por Joseph Albahari . Es uno de los mejores y más probados recursos disponibles.
Cuando uso la palabra clave lock (C #), significa que mi clase es segura para subprocesos o no.
No No hay una bala mágica que pueda hacer que una clase sea segura para subprocesos. La palabra clave de lock es solo una de las muchas herramientas diferentes que se pueden usar para hacer que una clase sea segura para el acceso simultáneo por múltiples hilos. Pero, solo usar un lock no garantiza nada. Es el uso correcto de los mecanismos de sincronización lo que hace que el código sea seguro para subprocesos. Hay muchas maneras de usar estos mecanismos incorrectamente.
¿Cómo evalúo la seguridad del hilo de una clase? ¿Hay alguna prueba para asegurarse de que una clase es 100% segura para subprocesos?
¡Esta es la pregunta del millón! Es increíblemente difícil probar código multiproceso. La herramienta CHESS proporcionada por Microsoft Research es un intento de hacer la vida más fácil para los programadores concurrentes.
En MSDN algunas clases de .NET se describen así:
" Este tipo es seguro para subprocesos " .
o
" Los miembros públicos estáticos (compartidos en Visual Basic) de este tipo son seguros para subprocesos. No se garantiza que los miembros de instancias sean seguros para subprocesos".
Mi pregunta es: ¿qué características hacen que una clase sea segura para subprocesos?
¿Hay algún estándar, recomendación o guía para la programación de seguridad de subprocesos?
Cuando uso la palabra clave lock (C #), significa que mi clase es segura para subprocesos o no.
¿Cómo evalúo la seguridad del hilo de una clase? ¿Hay alguna prueba para asegurarse de que una clase es 100% segura para subprocesos?
Ejemplo:
public class MyClass
{
public void Method()
{
lock (this)
{
// Now, is my class 100% thread-safe like Microsoft classes?
}
}
type m_member1;
type m_member2;
}
Gracias
En primer lugar, no utilice el bloqueo (esto) .
Esto puede causar puntos muertos. Porque otro código puede bloquear ese mismo objeto fuera del alcance de la clase. Debe crear un Objeto local y usarlo como el bloqueo de la clase.
Segundo, la seguridad del hilo es un tema complicado. Hay toneladas de material sobre esto en la web.
Como regla general, todos los métodos públicos deben estar bloqueados y seguros para que la clase sea segura.
Explicación muy simple: el tipo seguro para subprocesos significa que no necesita ningún mecanismo de sincronización adicional cuando usa su tipo. Supongamos que puede crear una instancia pasando una referencia a otro subproceso (o varios subprocesos) y usar métodos / propiedades de ambos subprocesos sin ninguna sobrecarga adicional para la seguridad del subproceso.
Una clase generalmente se considera segura para subprocesos si sus métodos pueden ser invocados por múltiples subprocesos simultáneamente sin dañar el estado de la clase o causar efectos secundarios inesperados. Hay muchas razones por las que una clase puede no ser segura para subprocesos, aunque algunas razones comunes son que contiene algún estado que podría estar dañado en el acceso concurrente.
Hay varias formas de hacer que una clase sea segura para subprocesos:
- Hazlo inmutable, si una clase no contiene ningún estado, es seguro usarlo simultáneamente desde varios subprocesos.
- Emplear el bloqueo para reducir la concurrencia. Sin embargo, esto no es garantía de seguridad de subprocesos, solo garantiza que un bloque de código no se ejecutará simultáneamente por varios subprocesos. Si el estado se almacena entre invocaciones de métodos, esto podría volverse inconsistente.
Cómo crear una clase segura para subprocesos realmente depende de lo que quiera hacer con la clase en cuestión.
También debes preguntarte, ¿necesito hacer que mi clase sea segura para hilos? Un modelo común de la mayoría de los marcos de UI es que hay un solo hilo de interfaz de usuario. Por ejemplo, en WinForms, WPF y Silverlight, la mayoría de su código se ejecutará desde el subproceso de la interfaz de usuario, lo que significa que no tiene que incluir la seguridad de subprocesos en sus clases.
Una clase se considera segura para subprocesos si solo un subproceso a la vez puede modificar el estado de los objetos creados a partir de la clase O la clase proporciona tal funcionalidad que varios subprocesos pueden llamar a varios métodos de la clase al mismo tiempo.
Cuando uso la palabra clave lock (C #), significa que mi clase es segura para subprocesos o no. Cuando usa el bloqueo significa que la parte del código dentro del bloqueo {} es segura para subprocesos. No garantiza que su clase sea segura para subprocesos. Y como Yochai Timmer dijo que no es una buena idea lock(this)
¿Cómo evalúo la seguridad del hilo de una clase? ¿Hay alguna prueba para asegurarse de que una clase es 100% segura para subprocesos? No estoy seguro de que haya ninguna prueba porque siempre es posible en los subprocesos múltiples que está obteniendo resultados correctos por casualidad. Así que para estar seguro de que puede ir a través del código de clase para ver cómo se asegura de que sea seguro para subprocesos