¿Por qué los objetos inmutables son seguros para subprocesos?

Question

class Unit { 
    private readonly string name; 
    private readonly double scale; 

    public Unit(string name, double scale) { 
     this.name = name; 
     this.scale = scale, 
    } 

    public string Name { get { return name; } } 
    public string Scale { get { return scale; } } 

    private static Unit gram = new Unit("Gram", 1.0); 

    public Unit Gram { get { return gram; } } 
} 

Varios hilos tienen acceso a Unit.Gram. ¿Por qué está bien que varios hilos lean simultáneamente Unit.Gram.Title?

Mi preocupación es que se están refiriendo a la misma ubicación de memoria. Un hilo comienza a leer esa memoria, entonces, ¿no está "bloqueado"? ¿El .NET maneja la sincronización para esta sección crítica debajo? ¿O me equivoco al pensar que la lectura simultánea necesita sincronización?

Answer 1

creo que su pregunta resulta no estar a punto de hilo de seguridad o inmutablity pero sobre los detalles (muy) bajos del acceso a la memoria.

Y ese es un tema importante, pero la respuesta corta es: Sí, dos hilos (y más importante, 2 + CPU) pueden leer (y/o escribir) la misma pieza de memoria simultáneamente.

Y mientras el contenido de esa área de memoria sea inmutable, se resuelven todos los problemas. Cuando puede cambiar, existe toda una gama de problemas, la palabra clave volatile y la clase Interlocked son algunas de las herramientas que utilizamos para resolverlos.

Answer 2

Si el objeto es inmutable, su estado nunca cambiará. Por lo tanto, las preocupaciones de los datos obsoletos salen por la ventana. La lectura de subprocesos nunca está bloqueada, por lo tanto, esto no es un problema (interbloqueo)

Answer 3

¿Qué hace que un objeto no sea seguro para subprocesos? Un objeto no es seguro para subprocesos si el valor/estado de ese objeto puede cambiar mientras un hilo lo está leyendo. Esto generalmente ocurre si un segundo hilo cambia el valor de este objeto mientras el primer hilo lo está leyendo.

Un objeto inmutable, por definición, no puede cambiar el valor/estado. Como cada vez que lee un objeto inmutable tiene el mismo valor/estado, puede tener cualquier cantidad de hilos que lean ese objeto sin preocupaciones.

Answer 4

Lecturas simultáneas no necesita sincronización. Como la sincronización solo es necesaria para los escritores (o los lectores y al menos un escritor), los objetos inmutables no requieren sincronización y, por lo tanto, son seguros para la realización de los hilos.

Answer 5

Las lecturas concurrentes no requieren sincronización en la gran mayoría de los casos (las excepciones son cosas como IO con memoria asignada donde la lectura desde una dirección determinada puede causar efectos secundarios).

Si las lecturas concurrentes requerían sincronización, sería prácticamente imposible escribir código multihilo de manera útil. Para ejecutar un fragmento de código, por ejemplo, el procesador debe leer la secuencia de instrucciones, ¿cómo escribiría una función de bloqueo si la función misma tuviera que protegerse contra la ejecución simultánea de este?

Answer 6

Memory Management Units son la parte del procesador que maneja la lectura de la memoria. Si tiene más de uno, una vez en una luna azul, 2 de ellos podrían tratar de leer la misma ubicación de memoria en la misma docena de nano segundos, pero no aparecen problemas ya que obtienen la misma respuesta.

Answer 7

Además de excepciones como la memoria mapeada para los controladores, por ejemplo, no hay ningún problema para que dos hilos lean simultáneamente la misma dirección de memoria. Un problema puede surgir cuando un hilo realiza algunos escribiendo datos sin embargo. En este caso, otros hilos pueden evitarse para leer ese objeto/datos.

Pero el problema no es debido a la simultaneidad de los escritos (en el nivel más bajo electrónica que ocurren uno tras otro todos modos), el problema es más bien que el objeto/conjunto de datos puede perder su consistencia. Usualmente uno utiliza un section critic para aislar algún código que puede no ser leído/escrito simultáneamente por otros hilos.

Hay muchos ejemplos sobre la red, pero tenga en cuenta lo siguiente, con price es un miembro privado de una clase, digamos del producto, que también tiene 2 métodos

public void setPrice(int value) { 
    price = value; 
    // -- point CRITIC -- 
    price += TAX; 
} 

public int getPrice() { 
    return price; 
} 

setPrice (v) fija el precio de un producto a v, y ajústelo con IVA (el programa debería tener value += TAX; price = value pero este no es el punto aquí :-)

Si el hilo A escribe el precio 100, y el TAX es (fijo) 1, el precio del producto finalmente establecerse en 101. Pero, ¿qué sucede si el hilo B lee el precio a través de getPrice() mientras que el hilo A está en point CRITIC? El precio devuelto a B perderá el IMPUESTO y se equivocará.

setPrice() debe dentro de una sección crítica (lock), para evitar cualquier acceso al objeto durante la fijación del precio

lock(this) 
    { 
     price = value; 
     price += TAX; 
    } 

Answer 8

La lectura de la misma ubicación de memoria solo se puede realizar en un ciclo de CPU por un hilo específico. El orden de lectura en este caso no importa ya que el valor subyacente no cambia. Por lo tanto, no hay posibilidad de que una lectura sea inconsistente, por lo que no es necesario sincronizar en ningún nivel en este caso.