La necessità di un modificatore volatile nel blocco a doppio controllo in .NET

Testi multipli dicono che quando si implementa il blocco con doppio controllo in .NET, il campo su cui si sta bloccando dovrebbe avere un modificatore volatile applicato. Ma perché esattamente? Considerando il seguente esempio:

public sealed class Singleton
{
   private static volatile Singleton instance;
   private static object syncRoot = new Object();

   private Singleton() {}

   public static Singleton Instance
   {
      get 
      {
         if (instance == null) 
         {
            lock (syncRoot) 
            {
               if (instance == null) 
                  instance = new Singleton();
            }
         }

         return instance;
      }
   }
}

perché "lock (syncRoot)" non realizza la necessaria consistenza della memoria? Non è vero che dopo l'istruzione "lock" sia la lettura che la scrittura sarebbero volatili e quindi si otterrebbe la necessaria coerenza?

Volatile non è necessario. Beh, una specie di **

volatileviene utilizzato per creare una barriera di memoria * tra le letture e le scritture sulla variabile.
lock, quando viene utilizzato, provoca la creazione di barriere di memoria attorno al blocco all'interno di lock, oltre a limitare l'accesso al blocco a un thread.
Le barriere di memoria fanno in modo che ogni thread legga il valore più corrente della variabile (non un valore locale memorizzato nella cache in qualche registro) e che il compilatore non riordini le istruzioni. L'uso volatilenon è necessario ** perché hai già un lucchetto.

Joseph Albahari spiega queste cose in modo migliore di quanto potrei mai fare.

E assicurati di controllare la guida di Jon Skeet per implementare il singleton in C #

update :
* volatilefa sì che le letture della variabile siano se le VolatileReadscritture siano VolatileWrites, che su x86 e x64 su CLR, sono implementate con un file MemoryBarrier. Possono essere a grana più fine su altri sistemi.

** la mia risposta è corretta solo se utilizzi CLR su processori x86 e x64. Esso potrebbe essere vero in altri modelli di memoria, come su Mono (e altre implementazioni), Itanium64 e l'hardware futuro. Questo è ciò a cui si riferisce Jon nel suo articolo nei "trucchi" per il bloccaggio a doppio controllo.

Fare uno dei {contrassegnare la variabile come volatile, leggerlo con Thread.VolatileReado inserire una chiamata a Thread.MemoryBarrier} potrebbe essere necessario affinché il codice funzioni correttamente in una situazione di modello di memoria debole.

Da quanto ho capito, su CLR (anche su IA64), le scritture non vengono mai riordinate (le scritture hanno sempre la semantica di rilascio). Tuttavia, su IA64, le letture possono essere riordinate prima delle scritture, a meno che non siano contrassegnate come volatili. Sfortunatamente, non ho accesso all'hardware IA64 con cui giocare, quindi qualsiasi cosa dica al riguardo sarebbe una speculazione.

Ho anche trovato utili questi articoli:
http://www.codeproject.com/KB/tips/MemoryBarrier.aspx
articolo di vance morrison (tutto si collega a questo, parla del blocco a doppio controllo)
articolo di chris brumme (tutto si collega a questo )
Joe Duffy: Varianti non funzionanti della chiusura a doppio controllo

La serie di luis abreu sul multithreading offre anche una bella panoramica dei concetti
http://msmvps.com/blogs/luisabreu/archive/2009/06/29/multithreading-load-and-store-reordering.aspx
http: // msmvps. com / blogs / luisabreu / archive / 2009/07/03 / multithreading-introducing-memory-fences.aspx

C'è un modo per implementarlo senza volatile campo. Lo spiego io ...

Penso che sia pericoloso riordinare l'accesso alla memoria all'interno del blocco, in modo tale da poter ottenere un'istanza non inizializzata completamente al di fuori del blocco. Per evitare ciò, faccio questo:

public sealed class Singleton
{
   private static Singleton instance;
   private static object syncRoot = new Object();

   private Singleton() {}

   public static Singleton Instance
   {
      get 
      {
         // very fast test, without implicit memory barriers or locks
         if (instance == null)
         {
            lock (syncRoot)
            {
               if (instance == null)
               {
                    var temp = new Singleton();

                    // ensures that the instance is well initialized,
                    // and only then, it assigns the static variable.
                    System.Threading.Thread.MemoryBarrier();
                    instance = temp;
               }
            }
         }

         return instance;
      }
   }
}

Capire il codice

Immagina che ci sia del codice di inizializzazione all'interno del costruttore della classe Singleton. Se queste istruzioni vengono riordinate dopo che il campo è stato impostato con l'indirizzo del nuovo oggetto, allora hai un'istanza incompleta ... immagina che la classe abbia questo codice:

private int _value;
public int Value { get { return this._value; } }

private Singleton()
{
    this._value = 1;
}

Ora immagina una chiamata al costruttore usando l'operatore new:

instance = new Singleton();

Questo può essere esteso a queste operazioni:

ptr = allocate memory for Singleton;
set ptr._value to 1;
set Singleton.instance to ptr;

E se riordino queste istruzioni in questo modo:

ptr = allocate memory for Singleton;
set Singleton.instance to ptr;
set ptr._value to 1;

Fa differenza? NO se pensi a un solo thread. SÌ se pensi a più thread ... cosa succede se il thread viene interrotto subito dopo set instance to ptr:

ptr = allocate memory for Singleton;
set Singleton.instance to ptr;
-- thread interruped here, this can happen inside a lock --
set ptr._value to 1; -- Singleton.instance is not completelly initialized

Questo è ciò che la barriera della memoria evita, non consentendo il riordino dell'accesso alla memoria:

ptr = allocate memory for Singleton;
set temp to ptr; // temp is a local variable (that is important)
set ptr._value to 1;
-- memory barrier... cannot reorder writes after this point, or reads before it --
-- Singleton.instance is still null --
set Singleton.instance to temp;

Buona programmazione!

Non credo che nessuno abbia effettivamente risposto alla domanda , quindi proverò.

Il volatile e il primo if (instance == null)non sono "necessari". Il blocco renderà questo codice thread-safe.

Quindi la domanda è: perché dovresti aggiungere il primo if (instance == null)?

Il motivo è presumibilmente quello di evitare di eseguire inutilmente la sezione di codice bloccata. Mentre si esegue il codice all'interno del blocco, qualsiasi altro thread che tenta di eseguire anche quel codice viene bloccato, il che rallenterà il programma se si tenta di accedere frequentemente al singleton da molti thread. A seconda della lingua / piattaforma, potrebbero esserci anche dei sovraccarichi dalla serratura stessa che si desidera evitare.

Quindi il primo controllo nullo viene aggiunto come un modo molto rapido per vedere se è necessario il blocco. Se non è necessario creare il singleton, è possibile evitare completamente il blocco.

Ma non puoi controllare se il riferimento è nullo senza bloccarlo in qualche modo, perché a causa del caching del processore, un altro thread potrebbe cambiarlo e tu leggeresti un valore "non aggiornato" che ti porterebbe a inserire il blocco inutilmente. Ma stai cercando di evitare una serratura!

Quindi rendi il singleton volatile per assicurarti di leggere il valore più recente, senza la necessità di utilizzare un blocco.

Hai ancora bisogno del lucchetto interno perché volatile ti protegge solo durante un singolo accesso alla variabile: non puoi testarlo e impostarlo in modo sicuro senza utilizzare un lucchetto.

Ora, è davvero utile?

Beh, direi "nella maggior parte dei casi, no".

Se Singleton.Instance potesse causare inefficienza a causa dei blocchi, allora perché lo chiami così spesso che questo sarebbe un problema significativo ? Il punto centrale di un singleton è che ce n'è solo uno, quindi il tuo codice può leggere e memorizzare nella cache il riferimento singleton una volta.

L'unico caso in cui riesco a pensare a dove questa memorizzazione nella cache non sarebbe possibile sarebbe quando si dispone di un numero elevato di thread (ad esempio un server che utilizza un nuovo thread per elaborare ogni richiesta potrebbe creare milioni di thread a esecuzione molto breve, ciascuno dei che dovrebbe chiamare Singleton.Instance una volta).

Quindi sospetto che il doppio controllo del blocco sia un meccanismo che ha un posto reale in casi molto specifici critici per le prestazioni, e quindi tutti si sono arrampicati sul carro del "questo è il modo corretto di farlo" senza realmente pensare a cosa fa e se sarà effettivamente necessario nel caso in cui lo stiano usando.

È necessario utilizzare volatile con il modello di blocco del doppio controllo.

La maggior parte delle persone indica questo articolo come prova che non hai bisogno di volatile: https://msdn.microsoft.com/en-us/magazine/cc163715.aspx#S10

Ma non riescono a leggere fino alla fine: " Un'ultima parola di avvertimento - Sto solo indovinando il modello di memoria x86 dal comportamento osservato sui processori esistenti. Pertanto anche le tecniche di blocco basso sono fragili perché l'hardware e i compilatori possono diventare più aggressivi nel tempo . Ecco alcune strategie per ridurre al minimo l'impatto di questa fragilità sul tuo codice. Innanzitutto, quando possibile, evita tecniche di low-lock. (...) Infine, ipotizza il modello di memoria più debole possibile, utilizzando dichiarazioni volatili invece di affidarti a garanzie implicite . "

Se hai bisogno di più convincimento, leggi questo articolo sulle specifiche ECMA che verranno utilizzate per altre piattaforme: msdn.microsoft.com/en-us/magazine/jj863136.aspx

Se hai bisogno di ulteriore convincimento, leggi questo articolo più recente in cui potrebbero essere inserite ottimizzazioni che impediscono il funzionamento senza volatile: msdn.microsoft.com/en-us/magazine/jj883956.aspx

In sintesi, "potrebbe" funzionare per te senza volatile per il momento, ma non rischiare che scriva il codice corretto e utilizzi il metodo volatile o volatileread / write. Gli articoli che suggeriscono di fare diversamente a volte tralasciano alcuni dei possibili rischi delle ottimizzazioni JIT / compilatore che potrebbero avere un impatto sul tuo codice, così come noi future ottimizzazioni che potrebbero verificarsi che potrebbero rompere il tuo codice. Inoltre, come accennato nell'ultimo articolo, i presupposti precedenti di lavorare senza volatile potrebbero già non reggere su ARM.

AFAIK (e - prendi questo con cautela, non sto facendo molte cose simultanee) no. Il blocco ti dà solo la sincronizzazione tra più contendenti (thread).

volatile d'altra parte dice alla tua macchina di rivalutare il valore ogni volta, in modo da non incappare in un valore memorizzato nella cache (e sbagliato).

Vedi http://msdn.microsoft.com/en-us/library/ms998558.aspx e prendi nota della seguente citazione:

Inoltre, la variabile viene dichiarata volatile per garantire che l'assegnazione alla variabile di istanza venga completata prima che sia possibile accedere alla variabile di istanza.

Una descrizione di volatile: http://msdn.microsoft.com/en-us/library/x13ttww7%28VS.71%29.aspx

Penso di aver trovato quello che stavo cercando. I dettagli sono in questo articolo: http://msdn.microsoft.com/en-us/magazine/cc163715.aspx#S10 .

Per riassumere - in .NET il modificatore volatile non è effettivamente necessario in questa situazione. Tuttavia, nei modelli di memoria più deboli, le scritture effettuate nel costruttore di un oggetto avviato in modo lento possono essere ritardate dopo la scrittura sul campo, quindi altri thread potrebbero leggere istanze non nulle danneggiate nella prima istruzione if.

Il lockè sufficiente. La specifica del linguaggio MS (3.0) menziona questo scenario esatto nel §8.12, senza alcuna menzione di volatile:

Un approccio migliore consiste nel sincronizzare l'accesso ai dati statici bloccando un oggetto statico privato. Per esempio:

class Cache
{
    private static object synchronizationObject = new object();
    public static void Add(object x) {
        lock (Cache.synchronizationObject) {
          ...
        }
    }
    public static void Remove(object x) {
        lock (Cache.synchronizationObject) {
          ...
        }
    }
}

Questo è un bel post sull'utilizzo di volatile con blocco a doppio controllo:

http://tech.puredanger.com/2007/06/15/double-checked-locking/

In Java, se lo scopo è proteggere una variabile non è necessario bloccarla se è contrassegnata come volatile