c# - form - ¿Es una asignación de referencia threadsafe?

c# thread windows form example

Question

Estoy construyendo un caché multiproceso en C #, que contendrá una lista de objetos Car:

public static IList<Car> Cars {get; private set;}

Me pregunto si es seguro cambiar la referencia en un hilo sin bloquearlo.

p.ej

private static void Loop()
{
  while (true)
  {
    Cars = GetFreshListFromServer();
    Thread.Sleep(SomeInterval);
  }
}

Básicamente se trata de si la asignación de una nueva referencia a Cars es atómica o no, supongo.

Si no es así, obviamente tendré que usar un campo privado para mis autos, y asegurarme de obtener los ajustes.

Answer 1

En la respuesta de @Marc Gravell, como se menciona en C # Language Spec 5.5, es importante saber qué se entiende por el término "tipo definido por el usuario". No he encontrado una definición clara de este uso en la especificación del lenguaje C #. En el UML y en el lenguaje común, una clase es una instancia de un tipo. Pero en el contexto de la especificación del lenguaje C #, su significado no está claro.

La sección de referencia del lenguaje de Visual Basic "Tipos definidos por el usuario" (en https://msdn.microsoft.com/en-us/library/cec05s9z.aspx ) dice

"Las versiones anteriores de Visual Basic admiten el tipo definido por el usuario (UDT). La versión actual expande el UDT a una estructura".

por lo que parece que un tipo definido por el usuario es una estructura, no una clase.

Pero ....

De acuerdo con la "Guía de programación de C #", sección "Tipos" (en https://msdn.microsoft.com/en-us/library/ms173104.aspx ):

"Un programa típico de C # utiliza tipos de la biblioteca de clases, así como tipos definidos por el usuario"

lo que implica que una clase es un tipo definido por el usuario. Más tarde, da un ejemplo de "tipos complejos definidos por el usuario:"

MyClass myClass;

lo que significa que "MyClass" es un tipo definido por el usuario. Y luego dice:

"Cada tipo en el CTS se define como un tipo de valor o un tipo de referencia. Esto incluye todos los tipos personalizados en la biblioteca de clases de .NET Framework y también sus propios tipos definidos por el usuario ".

... lo que implicaría que todas las clases creadas por un desarrollador son un "tipo definido por el usuario".

Y, finalmente, existe este elemento Stackoverflow en el que el significado de este término se debate inconclusamente: ¿Cómo determino si una propiedad es un tipo definido por el usuario en C #?

Por lo tanto, para estar seguro, me veo obligado a considerar todas las clases, ya sean las que creo o las que se encuentran en .Net Framework, todas ellas definidas por el usuario y, por lo tanto, no son seguras para la asignación, porque dice C # Especificación de idioma, sección 5.5:

No se garantiza que las lecturas y escrituras de ... así como los tipos definidos por el usuario sean atómicos.

Es desafortunado que un término coloquial se use en una especificación precisa como la Especificación del lenguaje C #. Debido a esta ambigüedad, para estar seguro de subprocesos, puedo escribir un código menos óptimo de lo que sería posible si resulta que "Tipo definido por el usuario" no incluye clases CLR.

Por lo tanto, estoy pidiendo más aclaraciones sobre esta respuesta de stackoverflow, ya que la base actual de la respuesta deja esta ambigüedad significativa. Tal como están las cosas, la respuesta a la pregunta " ¿Es una tarea de referencia enhebrable? " Parece ser " NO ".

Answer 2

Sí, se garantiza que las actualizaciones de referencia serán atómicas en la especificación del idioma.

5.5 Atomicidad de las referencias variables

Las lecturas y escrituras de los siguientes tipos de datos son atómicos: bool, char, byte, sbyte, corto, ushort, uint, int, float y tipos de referencia. Además, las lecturas y escrituras de tipos enum con un tipo subyacente en la lista anterior también son atómicas. No se garantiza que las lecturas y escrituras de otros tipos, incluidos long, ulong, double y decimal, así como los tipos definidos por el usuario, sean atómicas.

Sin embargo, dentro de un circuito cerrado puede ser mordido por el almacenamiento en caché de registro. Es improbable en este caso a menos que su método-llamada esté en línea (lo que podría suceder). Personalmente, agregaría el lock para hacerlo simple y predecible, pero volatile puede ayudar aquí. Y tenga en cuenta que la seguridad de hilos completa es más que solo atomicidad.

En el caso de un caché, estaría buscando Interlocked.CompareExchange , personalmente, es decir, intente actualizar, pero si falla rehaga el trabajo desde cero (comenzando desde el nuevo valor) y vuelva a intentarlo.