En muchos documentos de MSDN, esto se escribe bajo el encabezado Seguridad de subprocesos;msdn: ¿Qué es "Seguridad de subprocesos"?
"Cualquier miembro público estático (Shared en Visual Basic) de este tipo es seguro para subprocesos. No se garantiza que los miembros de instancia sean seguros para subprocesos".
por ejemplo; here
¿alguien puede explicarlo por favor de una manera bastante simple? Gracias :)
Eric Lippert tiene una excelente blog post acerca de esto. Básicamente es algo sin sentido por sí mismo.
Personalmente no confío mucho en MSDN en este frente, cuando veo esa placa de caldera. No siempre significa lo que dice. Por ejemplo, dice lo mismo acerca de Encoding, a pesar del hecho de que todos usamos codificaciones de múltiples hilos por todos lados.
A menos que tenga alguna razón para creer lo contrario (lo cual hago con Encoding), supongo que puedo llamar a cualquier miembro estático de cualquier hilo sin corrupción de estado global. Si quiero usar instancia miembros del mismo objeto de diferentes hilos, supongo que está bien si me aseguro, mediante el bloqueo, que solo un hilo usará el objeto a la vez. (Esto no siempre es el caso, por supuesto. Algunos objetos tienen afinidad hilo y activamente no les gusta que se utiliza desde varios subprocesos, incluso con bloqueo en su lugar. Controles de interfaz de usuario son el ejemplo obvio.)
Por supuesto, se hace complicado si los objetos se están compartiendo de forma no obvia: si tengo dos objetos que comparten una referencia a un tercero, entonces puedo terminar usando los dos primeros objetos independientemente de diferentes hilos, con el bloqueo correcto, pero aún así corrompo el tercer objeto .
Si un tipo hace anunciarse a sí mismo como seguro para subprocesos, espero que proporcione algunos detalles al respecto.Es fácil si es inmutable: puedes usar instancias como quieras sin preocuparte por ellas. Es parcial o totalmente "hilo-seguro" tipos que son mutables donde los detalles importan mucho.
Puede acceder a cualquier miembro estático público de esa clase desde varios subprocesos al mismo tiempo, y no interrumpir el estado de la clase. Si varios subprocesos intentan acceder al objeto utilizando métodos de instancia (esos métodos no marcados como "estáticos") al mismo tiempo, el objeto puede dañarse.
Una clase es "segura para subprocesos" si intenta tener acceso a la misma instancia de la clase desde varios subprocesos al mismo tiempo que no causa problemas.
Un objeto que es "seguro para hilos" significa que si dos hilos lo están usando en (o muy cerca, en sistemas de una sola CPU) al mismo tiempo, no hay posibilidad de que se corrompa por dicho acceso. Eso generalmente se logra al adquirir y soltar bloqueos, lo que puede causar cuellos de botella, por lo que "hilo seguro" también puede significar "lento" si está hecho cuando no es necesario.
Se espera que los miembros públicos estén compartidos entre los hilos (Nota, VB incluso llama a "Compartido"), por lo que las estadísticas públicas generalmente se hacen de tal manera que se pueden usar de forma segura.
Los miembros de instancias generalmente no son seguros para subprocesos, porque en el caso general ralentizarán las cosas. Si tiene un objeto que quiere compartir entre hilos, por lo tanto, tendrá que hacer su propia sincronización/bloqueo.
Para entender esto, considere el siguiente ejemplo. En la descripción de MSDN de .net clase HashSet, hay una parte que dice sobre la seguridad de la secuencia. En el caso de la clase HashSet, MSDN dice: "Cualquier miembro público estático (compartido en Visual Basic) de este tipo es seguro para subprocesos. No se garantiza que ningún miembro de instancia sea seguro para subprocesos. " De causa que todos conocemos el concepto de condiciones de carrera y puntos muertos, ¿pero qué quiere decir Microsoft en inglés simple? Si dos subprocesos agregan dos valores a una "instancia" de un HashSet, hay alguna situación en la que podemos obtener su recuento como uno. Causa en esta situación, el objeto HashSet está dañado ya que ahora tenemos dos objetos en el HashSet, pero su recuento solo muestra uno. Sin embargo, la versión estática pública de HashSet nunca se enfrentará a una corrupción de este tipo, incluso si dos subprocesos agregan valores simultáneamente.
Lo que la pequeña nota de MS significa es, "No hicimos mucho/ningún bloqueo en los métodos de instancia [probablemente por razones de rendimiento]. Así que si vas y le pones una docena de hilos encima, y se estropea, no lo hagas" Ven a llorar a nosotros. No es un error. Y te lo advertimos ". – cHao
@cHao: hay * mucho * más para obtener varios subprocesos en lugar de simplemente bloquear los métodos de instancia. A menudo, desea hacer que una * serie * completa de llamadas a métodos funcione atómicamente; en ese caso, ninguna cantidad de bloqueo interno ayudará. Iterar a través de una colección es el ejemplo obvio. –
@Jon: De acuerdo, hay mucho más. Pero no se puede esperar mucho más de MS, ya que la atomicidad incorporada en múltiples llamadas a los métodos ni siquiera tiene sentido para cualquiera que valore la estabilidad. (Exigiría que los documentos API digan cosas como "Si llamas a IsEmpty() y devuelve falso, DEBES llamar a Remove() o ReleaseLock() para evitar deadlocks".) E incluso en un único método, puede causar problemas de rendimiento si se usa innecesariamente. Entonces, MS no se molestó. Ese es mi punto. – cHao