Sind beim Verbinden eines Threads Speicherbarrieren erforderlich?

Question

Wenn ein Thread A einen anderen Thread B mit dem einzigen Zweck erzeugt, in eine Variable V zu schreiben und dann darauf wartet, dass er beendet wird, sind Speicherbarrieren erforderlich, um sicherzustellen, dass nachfolgende Lesevorgänge von V auf Thread A frisch sind? Ich bin mir nicht sicher, ob es implizite Barrieren bei den Beendigungs-/Beitrittsvorgängen gibt, die sie überflüssig machen.

Hier ist ein Beispiel:

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; 
} 

entweder/beide (oder mehrere) der Barrieren in den obigen Schnipseln sind erforderlich?

Answer 1

Aus der Dokumentation sieht es aus wie sie nicht benötigt werden -

Memory auf Multiprozessorsystemen mit schwachen Speicherordnungs nur erforderlich ist (beispielsweise ein System mit mehreren Intel Itanium-Prozessoren verwendet wird).

Für die meisten Zwecke bieten die C# lock-Anweisung, die Visual Basic SyncLock-Anweisung oder die Monitor-Klasse einfachere Möglichkeiten zum Synchronisieren von Daten.

Da Sie blockieren mit Join ist es noch mehr nicht notwendig.

Answer 2

Sie benötigen die erste Speicherbarriere nicht. Sie müssen diese nur aufrufen, bevor Sie auf Daten zugreifen können, die in einem separaten Thread geändert wurden. Da Sie nicht innerhalb 'thread' tun, brauchen Sie den Anruf nicht.

Sie können die zweite loswerden, wenn Sie planen, den Anruf beizubehalten. Wenn Sie den zweiten Anruf behalten, können Sie Join loswerden.

Answer 3

Nein, Synchronisationsmechanismen generieren implizite Speicherzäune. Alle Daten, die von einem Thread geändert wurden, sind nach dem Verbinden des Threads sichtbar.