Sono necessarie barriere di memoria quando si unisce a un thread?

Question

Se un thread A genera un altro thread B con il solo scopo di scrivere su una variabile V e quindi attende che termini, sono necessarie barriere di memoria per garantire che le letture successive di V sul thread A siano fresche? Non sono sicuro che ci siano barriere implicite nelle operazioni di terminazione/unione che le rendono ridondanti.

Ecco un esempio:

public static T ExecuteWithCustomStackSize<T> 
    (Func<T> func, int stackSize) 
{ 
    T result = default(T); 

    var thread = new Thread(
     () => 
       { 
        result = func(); 
        Thread.MemoryBarrier(); // Required? 
       } 
     , stackSize); 

    thread.Start(); 
    thread.Join(); 

    Thread.MemoryBarrier(); // Required? 
    return result; 
} 

Sono sono o/sia (o più) delle barriere del frammento precedente richiesta?

Answer 1

Dalla documentazione sembra che non sono richiesti -

MemoryBarrier è necessaria solo nei sistemi multiprocessore con debole ordinamento memoria (ad esempio, un sistema che impiega più processori Intel Itanium).

Per la maggior parte degli scopi, l'istruzione C# lock, l'istruzione SyncLock di Visual Basic o la classe Monitor forniscono modi più semplici per sincronizzare i dati.

Come si sta bloccando con join è ancora più necessario.

Answer 2

Non è necessaria la prima barriera di memoria. Devi solo chiamarli prima di accedere ai dati che sono stati modificati in un thread separato. Dato che non lo si fa all'interno di 'thread', non è necessaria la chiamata.

È possibile sbarazzarsi del secondo se si intende mantenere la chiamata di Join. Se si mantiene la seconda chiamata, è possibile sbarazzarsi di Join.

Answer 3

No, i meccanismi di sincronizzazione generano recinzioni di memoria implicite. Tutti i dati modificati da un thread saranno visibili dopo il collegamento del thread.