2010-05-03 15 views

Respuesta

8

Puede obtener más información sobre Read After Write (RAW), Write after Write(WAW) and Write After Read (WAR) hazards para obtener más información sobre este tema. Estos peligros se refieren a procesos en línea, pero en realidad es el mismo problema que ocurre con multi-threading. Básicamente significa que dos subprocesos diferentes están actualizando la misma ubicación en la memoria y, si depende de estas actualizaciones en un orden determinado, se sorprenderá al ver que no puede garantizar el orden en que se producen las actualizaciones.

Por ejemplo, si tiene dos estados:

x = y + z; 
    r = x + z; 

en un solo hilo, entonces no tendrá ningún problema debido a que el valor de r será siempre constante. Sin embargo, en múltiples hilos, es posible que cualquiera de las declaraciones ocurra primero y el valor de r sea más difícil de predecir.

2

Hm. Básicamente están hablando de "problemas de visibilidad" y "problemas de reordenamiento" (esa terminología es más común al menos en Java IMO). Creo que este enlace: http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html#volatile explica de qué está hablando el tutorial, utilizando términos más comunes (quizás Sun intentó usar un vocabulario "más fácil" o algo así).

+0

1 para el enlace –

3

Básicamente, en ausencia de cualquier sincronización, los hilos pueden ver un valor diferente de campo simple. Considere este ejemplo:

class Foo 
{ 
    int bar = 0; 

    void unsafeCall () 
    { 
    final Foo thisObj = this; 

    Runnable r = new Runnable () 
    { 
     public void run () 
     { 
     thisObj.bar = 1; 
     } 
    } 

    Thread t = new Thread(); 

    t.start(); 
    Thread.sleep(1000); 

    // May print bar = 0 
    System.out.println("bar = " + bar); 
    } 
} 

La forma más sencilla de evitar el error de coherencia de memoria es declarar bar campo para ser volatile.

Este forzamiento de los hilos para volver a verificar la memoria se llama barrera de memoria. Otro ejemplo de barrera de memoria es un método/bloque synchronized.

1

encuentro un buen ejemplo al buscar esta pregunta. Como continuación:

 
    Accesses to main memory might not occur in the same 
    order that the CPU initiated them, particularly for writes 
    (which often go through hardware write buffers so the CPU 
    needn't wait for them). If CPU 1 writes the Answer to 
    location A and then writes the AnswerIsReady flag to B, 
    CPU 2 may see the change to B before it sees the change 
    to A, and thus get the WrongAnswer. Making either or both 
    writes atomic doesn't help; what's needed is something 
    called a "memory barrier." 

través http://www.velocityreviews.com/forums/t390825-memory-consistency-errors.html