Me gustaría saber si las propiedades implementadas automáticamente de C#, como public static T Prop { get; set; }, son seguras para hilos o no. ¡Gracias!¿Las propiedades estáticas autoejecutadas por C# son seguras para subprocesos?
Parece que no. Esta es la descompilación con Reflector:
private static string Test
{
[CompilerGenerated]
get
{
return <Test>k__BackingField;
}
[CompilerGenerated]
set
{
<Test>k__BackingField = value;
}
}
Eso está un poco mal. El modelo de memoria de .NET garantiza que las escrituras serán atómicas y vistas por todos los hilos, al menos para el .NET Framework normal, y si no son virtuales, siempre estarán en línea.Ambos son detalles de implementación del .NET desktop framework y no están garantizados por la especificación. –
er me refiero a que la descompilación es correcta, pero la forma en que se implementan garantiza la atomicidad, al menos para los enteros y los tipos de referencia (¡con la advertencia obvia de que la atomicidad! = Seguridad del hilo). Sin embargo, para longs/dobles/structs/etc., Estás solo. –
La especificación garantiza que cosas como 'Int32',' float' y referencias son ** atómicas **. No ofrece muchas garantías sobre la visibilidad de subprocesos/registro de almacenamiento en caché, etc. –
No, no son seguros para la rosca. Las propiedades estáticas son tan vulnerables como los campos estáticos a los problemas de concurrencia.
No lo creo. Creo que son solo azúcar sintético para:
private static T _prop;
public static T Prop
{
get { return _prop; }
set { _prop = value; }
}
No. Debe envolverlos en mecanismos de bloqueo de roscas.
object _lock = new object();
public static Main(string[] args)
{
lock(_lock)
{
Prop = new T();
}
T val = null;
lock(_lock)
{
val = Prop;
}
}
¿Qué es Prop? ¿Qué es T? –
Prop y T son de la pregunta. – Amy
No se proporciona sincronización con propiedades automáticas, incluidas las propiedades estáticas.
Si necesita seguridad total de hilos, querrá usar sus propias propiedades con un campo de respaldo, y manejar la sincronización usted mismo.
Para completar, los eventos de tipo campo hacen tienen seguridad integrada, pero están solos en esto. Las propiedades implementadas automáticamente no incluyen ninguna de estas características. Puede, sin embargo, hacer algo como:
public static double SomeProp
{ // ### NOT RECOMMENDED ###
[MethodImpl(MethodImplOptions.Synchronized)] get;
[MethodImpl(MethodImplOptions.Synchronized)] set;
}
El problema con esto es que va a bloquear la Type, que es una mala cosa. Implementaría mi propia sincronización para esto, personalmente.
"malo" por razones de "marshal-by-bleed" donde el bloqueo de tipo se filtra en otros appdomains aislados en el mismo proceso ... – x0n
Ya es suficientemente malo con solo decir una verdad del dominio de la aplicación. –
Sección 10.7.4 de la Especificación C# estados:
Cuando una propiedad se especifica como una propiedad implementado de forma automática, un campo respaldo oculto es automáticamente disponible para la propiedad, y las accessors son implementado para leer desde y escribir en ese campo de respaldo. El siguiente ejemplo:
public class Point {
public int X { get; set; } // automatically implemented
public int Y { get; set; } // automatically implemented
}
es equivalente a la siguiente declaración:
public class Point {
private int x;
private int y;
public int X { get { return x; } set { x = value; } }
public int Y { get { return y; } set { y = value; } }
}
Eso es lo que prometemos, y eso es lo que hay. El objetivo de las propiedades automotrices es hacer lo más básico, simple y barato; si quieres hacer algo más elegante, entonces debes escribir una propiedad "real".
Upvoted usted para hacer referencia a la especificación C# real. –
Primero tendrá que definir qué quiere decir con "hilo seguro" en esta instancia en particular. –
Por thread-safe Quiero decir, si escribo el valor en un hilo, y otro hilo intenta leerlo, podría el segundo hilo obtener un valor incorrecto. –