Qual è il costo della parola chiave volatile in un sistema multiprocessore?

Question

ci stiamo imbattendo in problemi di prestazioni, e un potenziale colpevole è un uso centralizzato di un singleton volatile. il codice specifico è della forma

class foo { 
    static volatile instance; 
    static object l = new object(); 

    public static foo Instance { 
    if (instance == null) 
     lock(l) { 
     if (instance == null) 
      instance = new foo(); 
     } 

    return foo(); 
    } 
} 

questo è in esecuzione su una scatola a 8 vie, e stiamo vedendo cambio di contesto per la somma di 500.000 al secondo. le risorse di sistema tipiche vanno bene - 25% cpu util, 25% memory util, IO basso, no paging, ecc.

utilizza un campo volatile per indurre una barriera di memoria o qualsiasi tipo di cache della cpu ricaricare? o va solo dopo la memoria principale ogni volta, solo per quel campo?

Answer 1

lock induce una barriera di memoria, quindi se si accede sempre all'istanza in un blocco non è necessario il volatile.

Secondo this site:

Il C# attrezzi parola chiave volatile acquisiscono e rilasciano la semantica, che implica una barriera di memoria lettura su lettura e una barriera di memoria di scrittura su scrittura.

Answer 2

Purtroppo, la Singleton prende una cattiva reputazione per quasi tutto :)

Questo non è il mio dominio di competenza, ma per quanto ne so non c'è nulla di speciale in volatili diverso dal compilatore/run -time NON riordinare lettura/scrittura (alla variabile) per scopi di ottimizzazione.

Modifica: I corretti. La volatilità non solo introduce barriere di memoria, ma ciò che accade (e incidentalmente, le prestazioni) dipende in gran parte dalla particolare CPU coinvolta. Vedi http://dotnetframeworkplanet.blogspot.com/2008/11/volatile-field-and-memory-barrier-look.html

Questo è il motivo per cui è ancora necessario il blocco.

Domande che possono/potrebbero non hanno ricevuto risposta già:

1. Qual è l'istanza Singleton effettivamente facendo? Forse il codice di istanza deve essere refactored ...
2. Qual è il numero di thread del processo in esecuzione? Una casella a 8 direzioni non ti aiuterà se hai un numero eccessivo di thread.
3. Se è più alto del previsto, perché?
4. Che altro è in esecuzione sul sistema?
5. Il problema di prestazioni è coerente?

Answer 3

Nel tuo esempio qui, volatile non dovrebbe essere oggetto di alcun "rallentamento". Il lock(), tuttavia, può comportare enormi roundtrip al kernel, specialmente se c'è un sacco di contesa per il lock.

Non c'è davvero alcun bisogno di bloccare il Singleton in questo caso, si può solo fare

class Foo { 
    static Foo instance = new Foo(); 
    public static Foo FooInstance() { 
    return instance ; 
    } 
} 

Naturalmente, se viene utilizzato in un sacco di diversi thread 'esempio', saresti ancora devono blocca() tutto ciò che altera quel Foo, a meno che tutti i metodi/le proprietà di Foo siano in sola lettura. ad es.

class Foo { 
     static Foo instance = new Foo(); 
     object l = new object(); 
     int doesntChange = 42; 
     int canChange = 123; 
     public static Foo FooInstance() { 
     return instance ; 
     } 
     public void Update(int newVal) { 
     lock(l) { // you'll get a lot of trouble without this lock if several threads accesses the same FOO. Atleast if they later on read that variable 
      canChange = newVal; 
     } 

     public int GetFixedVal() { 
     return doesntChange; //no need for a lock. the doesntChange is effectivly read only 
     } 
    } 

Answer 4

Non c'è davvero bisogno dell'uso di volatile per un singleton, come lo si sta impostando esattamente una volta - e bloccando il codice lo imposta. Vedi Jon Skeet's article on singletons per maggiori informazioni.

Answer 5

Una cosa che volatile non farà è causare un cambio di contesto. Se visualizzi 500.000 opzioni di contesto al secondo, significa che i tuoi thread stanno bloccando qualcosa e che volatile è non il colpevole.

Answer 6

La risposta breve è Sì, crea una barriera di memoria (svuota tutto e passa alla memoria principale, non solo quella singola variabile), ma No non sarà la causa del cambio di contesto.

Inoltre, come altri hanno già menzionato, non credo che qui sia necessario un volatile.