¿Se requieren barreras de memoria para unir un hilo?

Question

Si un hilo Un genera otro hilo B con el único propósito de escribir a una variable V y luego espera a que termine, presentan memoria barreras necesaria para asegurar que las lecturas siguientes de V en la rosca A son frescos? No estoy seguro si existen barreras implícitas en las operaciones de terminación/unión que las hacen redundantes.

He aquí un ejemplo:

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

Se están bien/los dos (o más) de las barreras en el fragmento anterior requiere?

Answer 1

De la documentación que parece que no son necesarios - se requiere

MemoryBarrier sólo en sistemas multiprocesador con una débil ordenamiento de memoria (por ejemplo, un sistema que utiliza múltiples procesadores Intel Itanium).

Para la mayoría de los propósitos, la declaración de C# de bloqueo, la instrucción de Visual Basic SyncLock, o de la clase monitor proporcionan formas más sencillas de sincronizar los datos.

Como estás bloqueando con unirse a ella es aún más no es necesario.

Answer 2

que no es necesario la primera barrera de memoria. Solo necesita llamarlos antes de acceder a los datos que se han modificado en un hilo separado. Dado que no lo está haciendo dentro de 'thread', no necesita la llamada.

Usted puede deshacerse de la segunda si se piensa en mantener la llamada Unir. Si mantiene la segunda llamada, puede deshacerse de Join.

Answer 3

No, los mecanismos de sincronización generan vallas de memoria implícita. Todos los datos modificados por un hilo serán visibles después de unir el hilo.