È il C# '??' thread operatore sicuro?

Question

Tutti sanno che questo non è thread-safe:

public StringBuilder Builder 
{ 
    get 
    { 
     if (_builder != null) 
      _builder = new StringBuilder(); 
     return _builder; 
    } 
} 

Che dire di questo?

public StringBuilder Builder 
{ 
    get { return _builder ?? (_builder = new StringBuilder()); } 
} 

Answer 1

BEGIN EDIT

Sulla base della sua titolo modificato, l'operatore null coalescenza stessa sembra essere thread-safe (vedi Phil Haack's analysis). Sembra, tuttavia, che non garantisce contro le potenziali chiamate multiple al costruttore StringBuilder.

FINE EDIT

Hai un problema più grande con filettatura, e cioè che la proprietà del costruttore stesso rappresenta stato che può essere condiviso tra i thread. Anche se si rende sicuro il thread di inizializzazione pigro, non è possibile garantire che i metodi che utilizzano Builder lo facciano in modalità thread-safe.

// below code makes the getter thread safe 
private object builderConstructionSynch = new object(); 
public StringBuilder Builder 
{ 
    get 
    { 
     lock (builderConstructionSynch) 
     { 
      if (_builder == null) _builder = new StringBuilder(); 
     } 
     return _builder; 
    } 
} 

È possibile che questo impedirà il problema filettatura nella inizializzazione differita di _builder, ma a meno che non si sincronizzano le chiamate ai metodi di StringBuilder esempio, non la garanzia di sicurezza filo in qualsiasi metodo che consumano la proprietà Builder. Questo perché i metodi di istanza in StringBuilder non sono stati progettati per essere thread-safe. Vedere il testo seguente da MSDN StringBuilder page.

statici pubblici (Shared in Visual Basic) di questo tipo sono thread sicuri. Qualsiasi membro di istanza non è garantito come thread-safe.

Se stai consumando StringBuilder in più thread, è probabile che tu lo stia meglio incapsulando nella tua classe. Fare Builder privato ed esporre ciò che il comportamento è necessario come un metodo pubblico:

public void AppendString(string toAppend) 
{ 
    lock (Builder) 
    { 
     Builder.Append(toAppend); 
    } 
} 

In questo modo non sta scrivendo codice di sincronizzazione in tutto il luogo.

Answer 2

NO per entrambe le versioni

Answer 3

che non più o meno è thread-safe; si potrebbero ancora avere due thread per il controllo nullo allo stesso tempo, quindi creare oggetti separati e non vedere l'altro.

Answer 4

No, non sono atomiche

Answer 5

Le risposte sono corrette, entrambi non sono threadsafe. In realtà, sono per lo più equivalenti e l'operatore ?? è semplicemente un compilatore magico per rendere il codice più snello. È necessario utilizzare un meccanismo di sincronizzazione se si desidera che diventi a prova di codice.

Answer 6

Non ho provato io stesso approccio, ma se si vuole la sicurezza dei thread senza il sovraccarico di un sistema di bloccaggio e non siete preoccupati per creando potenzialmente e scartando un oggetto esempio, si potrebbe provare questo:

using System.Threading; 

public StringBuilder Builder 
{ 
    get 
    { 
     if (_builder != null) 
      Interlocked.CompareExchange(ref _builder, new StringBuilder(), null); 
     return _builder; 
    } 
} 

La chiamata a CompareExchange() eseguirà una sostituzione atomica del valore in _builder con una nuova istanza di StringBuilder solo se _builder == null.Tutti i metodi sulla classe Interlocked sono garantiti per NON essere preceduti da interruttori di thread.