Che vantaggio c'è di memorizzare "questo" in una variabile locale in un metodo struct?

Question

stavo navigando l'albero dei sorgenti di .NET core oggi e attraversò di corsa this pattern in System.Collections.Immutable.ImmutableArray<T>:

T IList<T>.this[int index] 
{ 
    get 
    { 
     var self = this; 
     self.ThrowInvalidOperationIfNotInitialized(); 
     return self[index]; 
    } 
    set { throw new NotSupportedException(); } 
} 

Questo modello (memorizzazione this in una variabile locale) sembra essere coerentemente applicato in questo file ogni volta che altrimenti sarebbe fatto riferimento this più volte nello stesso metodo, ma non quando viene fatto riferimento una sola volta. Così ho iniziato a pensare a quali potrebbero essere i relativi vantaggi nel farlo in questo modo; mi sembra che il vantaggio sia probabilmente legato alle prestazioni, quindi ho seguito questa strada un po 'oltre ... forse trascurerò qualcos'altro.

Il CIL che viene emesso per il "negozio this in un locale" modello sembra essere simile a un ldarg.0, poi ldobj UnderlyingType, quindi stloc.0 in modo che i riferimenti successivi provengono da ldloc.0 invece di una nuda ldarg.0 come sarebbe ad appena utilizzare più volte this.

Forse ldarg.0 è significativamente più lento di ldloc.0, ma non abbastanza sia per il C# to-CIL traduzione o il jitter a cercare nuove opportunità per ottimizzare questo per noi, in modo tale che ha più senso di scrivere questo strano dall'aspetto modello in codice C# in qualsiasi momento altrimenti emetteremo due istruzioni ldarg.0 in un metodo di istanza struct?

Update: o, sai, ho potuto guardato i commenti all'inizio di quel file, che explain esattamente quello che sta succedendo ...

Answer 1

Come già notato, System.Collections.Immutable .ImmutableArray < T> è una struct :

public partial struct ImmutableArray<T> : ... 
{ 
    ... 

    T IList<T>.this[int index] 
    { 
     get 
     { 
      var self = this; 
      self.ThrowInvalidOperationIfNotInitialized(); 
      return self[index]; 
     } 
     set { throw new NotSupportedException(); } 
    } 

    ... 

var self = this; crea una copia della struct a cui si riferisce questo. Perché dovrebbe aver bisogno di farlo? Il source comments of this struct fornisce una spiegazione del motivo per cui è necessario:

/// Questo tipo deve essere thread-safe. Come una struttura, non può proteggere i suoi propri campi
/// venga modificata da un thread mentre i suoi membri sono in esecuzione su altri thread
/// perché le strutture possono cambiare in luogo semplicemente riassegnando campo contenente
/// questa struttura. Pertanto è estremamente importante che
/// ** Ogni membro dovrebbe solo dereferenziare questa volta. **
/// Se un membro deve fare riferimento al campo dell'array, ciò vale come dereferenziamento di questo.
/// Anche chiamare altri membri di istanza (proprietà o metodi) conta come dereferenziare questo.
/// Ogni membro che deve utilizzarlo più di una volta deve invece
/// assegnarlo a una variabile locale e utilizzarlo per il resto del codice.
/// Copia efficacemente un campo nella struttura in una variabile locale in modo che
/// sia isolato da altri thread.

In breve, se è possibile che altri thread stanno facendo modifiche a un campo della struttura o cambiare la struct in posizione (riassegnando un campo membro della classe di questo tipo struct, per esempio), mentre il metodo get è in esecuzione e quindi potrebbe causare effetti collaterali negativi, quindi diventa necessario che il metodo get faccia prima una copia (locale) della struct prima di elaborarla.

Aggiornamento: Si prega di leggere anche supercats answer, che spiega in dettaglio quali condizioni devono essere soddisfatte in modo che un'operazione come fare una copia locale di una struttura (cioè var self = this;) è di essere thread-safe, e che cosa potrebbe accadere se tali condizioni sono non soddisfatti.

Answer 2

Le istanze di struttura in .NET sono sempre modificabili se la posizione di archiviazione sottostante è modificabile e sempre immutabile se il percorso di archiviazione sottostante è immutabile. È possibile che i tipi di strutture "fingano" di essere immutabili, ma .NET consentirà alle istanze di tipo struttura di essere modificate da qualsiasi elemento che possa scrivere le posizioni di archiviazione in cui risiedono, e i tipi di struttura non hanno voce in capitolo.

Pertanto, se uno aveva una struct:

struct foo { 
    String x; 
    override String ToString() { 
    String result = x; 
    System.Threading.Thread.Sleep(2000); 
    return result & "+" & x; 
    } 
    foo(String xx) { x = xx; } 
} 

e si dovesse richiamare il seguente metodo su due fili con la stessa matrice myFoos di tipo foo[]:

myFoos[0] = new foo(DateTime.Now.ToString()); 
var st = myFoos[0].ToString(); 

sarebbe del tutto possibile che qualsiasi thread avviato per primo avrebbe il suo valore ToString() riportare il tempo scritto dalla sua chiamata al costruttore e il tempo riportato dalla chiamata del costruttore dell'altro thread, piuttosto che riportare la stessa stringa due volte. Per i metodi il cui scopo è quello di convalidare un campo di struttura e quindi utilizzarlo, se il campo cambia tra la convalida e l'uso, il metodo verrà utilizzato utilizzando un campo non convalidato. Copiando il contenuto del campo della struttura (copiando solo il campo o copiando l'intera struttura) si evita tale pericolo.

noti che per le strutture che contengono un campo di tipo Int64, UInt64 o Double, o che contengono più di un campo, è possibile che una dichiarazione come var temp=this; che si verifica in un thread mentre un altro thread sovrascrive la posizione in cui this è stato archiviato, potrebbe finire per copiare una struttura che contiene una miscela arbitraria di vecchi e nuovi contenuti. Solo quando una struttura contiene un singolo campo di un tipo di riferimento, o un singolo campo di una primitiva a 32 bit o più piccola, è garantito che una lettura che si verifica simultaneamente con una scrittura produrrà un certo valore che la struttura effettivamente possiede, e anche questo potrebbe avere qualche stranezza (es. almeno in VB.NET, una dichiarazione come someField = New foo("george") potrebbe cancellare someField prima di chiamare il costruttore).