multithreading - raspberry - programa de hilos en python

¿Se requiere una barrera de memoria si un segundo hilo espera la finalización del primero?

Question

Supongamos que el hilo Alpha está escribiendo en la variable A sin bloqueo. Un segundo hilo Beta está esperando a que Alpha finalice, luego lee la variable A por turno.

¿Es posible que el contenido de A no sea nuevo? ¿Se pueden retrasar las grabaciones de memoria más allá de la duración del hilo? ¿No funcionará implícitamente el mecanismo estándar de esperar la terminación Alpha hilo como una barrera de memoria?

ACTUALIZACIÓN 1

¿Hay algún ejemplo de espera que no incluya una barrera de memoria?

Answer 1

Esto depende de las garantías que ofrece la biblioteca de subprocesos. En particular, pthread_join () se define como una barrera de memoria . En la mayoría de los casos, la unión de hilos implicará una barrera de memoria, pero no es inconcebible que este no siempre sea el caso.

Answer 2

(Suponiendo que te estés refiriendo a C #).

Si se Thread.Join Thread literalmente, su respuesta depende de si Thread.Join genera implícitamente barreras de memoria (que, por las respuestas ya dadas, probablemente sí lo haga).

Sin embargo, si quiere decir que Alpha y Beta son tareas definidas por el usuario ejecutadas en un hilo de fondo (posiblemente del grupo de subprocesos), y que "esperar" se refiere a la sincronización de nivel de usuario entre las dos tareas , entonces es más probable que los datos no será fresco, a menos que se introduzca una construcción de señalización o una barrera explícita.

Aquí hay un ejemplo trivial:

public class Program
{
static string A = "foo";
static volatile bool isAlphaReady = false;
static void Alpha()
{
A = "bar";
isAlphaReady = true;
}
static void Beta()
{
while (!isAlphaReady)
; // Wait by polling
Console.WriteLine(A);
}
static void Main(string[] args)
{
new Thread(Alpha).Start();
new Thread(Beta).Start();
Console.ReadKey();
}
}

Aunque parece (intuitivamente) que Beta siempre producirá "bar" como el valor de A , esto no está garantizado en un sistema multiprocesador con un comportamiento de sincronización débil (como Itanium), en cuyo caso, se puede generar "foo" su lugar.

Answer 3

Casi con certeza (la API utilizada para esperar la finalización del hilo necesitaría usar barreras de memoria para sus propios fines), pero creo que para una respuesta definitiva necesitarás hablar sobre la API de threading específica que se utiliza.

Por ejemplo, posix hace tal garantía para pthread_join() : https://.com/a/3208140/12711

Y Win32 documenta que sus API de sincronización para esperar en un objeto (por ejemplo, un manejador de subprocesos) imponen barreras de memoria: http://msdn.microsoft.com/en-us/library/ms686355.aspx