Perché gli oggetti immutabili sono thread-safe?

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; } } 
} 

Più thread hanno accesso a Unit.Gram. Perché è ok per più thread contemporaneamente leggere Unit.Gram.Title?

La mia preoccupazione è che si riferiscono alla stessa posizione di memoria. Un thread inizia a leggere quella memoria, quindi non è "bloccato" allora? .NET gestisce la sincronizzazione per questa sezione critica sottostante? O sbaglio nel pensare che la lettura simultanea abbia bisogno di sincronizzazione?

Answer 1

Penso che la tua domanda risulta non essere di circa thread-sicurezza o immutabilità ma riguardo ai dettagli (molto) di basso livello dell'accesso alla memoria.

E questo è un argomento pesante ma la risposta breve è: Sì, due thread (e più importante, 2+ CPU) possono leggere (e/o scrivere) lo stesso pezzo di memoria simultaneamente.

E fintanto che il contenuto di tale area di memoria è immutabile, tutti i problemi sono risolti. Quando può cambiare, c'è tutta una serie di problemi, la parola chiave volatile e la classe Interlocked sono alcuni degli strumenti che usiamo per risolverli.

Answer 2

Se l'oggetto è immutabile, il suo stato non cambierà mai. Quindi le preoccupazioni dei dati obsoleti vanno fuori dalla finestra. La lettura del thread non è mai bloccata, quindi non è un problema (deadlock)

Answer 3

Cosa rende un oggetto non thread sicuro? Un oggetto non è thread-safe se il valore/stato di quell'oggetto può cambiare mentre un thread lo sta leggendo. Ciò accade generalmente se un secondo thread modifica il valore di questo oggetto mentre il primo thread lo sta leggendo.

Un oggetto immutabile, per definizione, non può modificare il valore/stato. Poiché ogni volta che leggi un oggetto immutabile ha lo stesso valore/stato, puoi avere un numero qualsiasi di thread che legge quell'oggetto senza preoccupazioni.

Answer 4

Le letture simultanee non devono essere sincronizzate con. Poiché la sincronizzazione è necessaria solo per gli scrittori (o lettori e almeno un writer), gli oggetti non modificabili non richiedono la sincronizzazione e sono quindi compatibili con il thread.

Answer 5

Le letture contemporanee non richiedono la sincronizzazione nella maggior parte dei casi (le eccezioni sono cose come l'I/O mappato in memoria in cui la lettura da un determinato indirizzo può causare effetti collaterali).

Se le letture simultanee richiedevano la sincronizzazione, sarebbe quasi impossibile scrivere codice multi-threadato in modo utile. Ad esempio, per eseguire una parte di codice, il processore deve leggere il flusso di istruzioni, come si scriverà una funzione di blocco se la funzione stessa deve proteggere contro se stessa eseguita contemporaneamente?

Answer 6

Memory Management Units sono la parte del processore che gestisce la lettura della memoria. Se ne hai più di una, una volta in una luna blu, 2 di loro potrebbero provare a leggere la stessa posizione di memoria nella stessa dozzina di nanosecondi, ma nessun problema risulta vedere quando ottengono la stessa risposta.

Answer 7

Oltre alle eccezioni come la memoria mappata per i driver, ad esempio, non esiste alcun problema per due thread che leggono contemporaneamente lo stesso indirizzo di memoria. Un problema può sorgere quando un thread esegue alcuni scrivendo i dati. In questo caso, è possibile impedire ad altri thread di leggere quell'oggetto/dati.

Ma il problema non è dovuto al simultaneità degli scritti (a livello elettronico più basso si verificano uno dopo l'altro in ogni caso), il problema è piuttosto che l'oggetto/set di dati può perdere la loro consistenza. Di solito si utilizza uno section critic per isolare del codice che potrebbe non essere letto/scritto contemporaneamente da altri thread.

Ci sono molti esempi in Rete, ma si consideri il seguente, con price è un membro privato di una classe, dire prodotto, che ha anche 2 metodi

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

public int getPrice() { 
    return price; 
} 

setPrice (v) fissa il prezzo di un prodotto a v, e aggiustarlo con IVA (il programma dovrebbe avere value += TAX; price = value ma questo non è il punto qui :-)

Se il thread A scrive 100, e TAX è (fisso) 1, il prezzo del prodotto sarà finalmente essere impostato su 101. Ma cosa succede se il thread B legge il prezzo tramite getPrice() mentre il thread A è point CRITIC? Il prezzo restituito a B salterà la TASSA e sarà sbagliato.

setPrice() dovrebbe all'interno di una sezione critica (lock), per evitare l'accesso all'oggetto durante l'impostazione del prezzo

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

Answer 8

La lettura della stessa posizione di memoria può essere eseguita in un ciclo della CPU solo da una filettatura specifica. L'ordine di lettura in questo caso non ha importanza poiché il valore sottostante non cambia. Pertanto non vi è alcuna possibilità che una lettura sia incoerente, quindi in questo caso non c'è bisogno di sincronizzazione a nessun livello.