Antes de responder a sus preguntas, debo señalar que las barreras de memoria afectan más que solo a la CPU. En realidad, hay dos modelos de memoria en funcionamiento cuando se ejecuta una aplicación. Uno está en el nivel de hardware y el otro en el nivel de software. Como desarrollador, debe codificar la combinación más débil de los diferentes elementos de ambos. Con el CLR y una arquitectura x86 esto generalmente significa que el CLR es más importante porque la arquitectura x86 en realidad tiene un modelo de memoria bastante sólido. En otras palabras, la palabra clave volatile y otros mecanismos de barreras de memoria afectarán la forma en que el JIT produce código también.
1.La lectura volátil le garantiza que lea el último valor de una variable. ¿Significa que obliga a todas las CPU a a vaciar sus valores en caché para esa variable ? solo esa variable o todo? Entonces, si fuerza a todas las CPU a vaciar escrituras en caché y obtener la última versión de la memoria principal, ¿se trata de una barrera de memoria ?
Primero, técnicamente una lectura volátil no garantiza que lea el último valor de una variable. Todo lo que realmente significa es que ninguna otra lectura o escritura puede ocurrir antes que la volátil. Sin embargo, el efecto es que la lectura debe provenir de la memoria principal si va precedida de otra lectura volátil. En segundo lugar, no, una lectura volátil no influye en otras escrituras, por lo que no obliga a todas las CPU a vaciar su caché de escritura. En tercer lugar, sí, una operación volátil se considera una barrera de la memoria.
2.La escritura rápida garantiza que se escribe un valor en la variable en la memoria principal. ¿Significa que anula todos los valores en caché para esa variable en todas las CPU ?
Similar a una lectura volátil, una escritura volátil es técnicamente de orden. Asegura que no puede haber ninguna otra lectura o escritura después de la volátil. No significa que la escritura en cuestión se compromete de inmediato. Solo afecta la CPU que ejecuta ese hilo. Curiosamente, la arquitectura x86 realmente trata todas las escrituras como volátiles. Pero, el CLR no (al menos, la especificación ECMA). Es por eso que todavía tiene que usar una operación volátil en las escrituras. Este es un ejemplo de codificación del elemento de modelo de memoria más débil tanto del hardware como del software.
3.¿Está utilizando una barrera de memoria cuando usa la palabra clave volátil?
Sí. Hay dos tipos de barreras de memoria. Vallas llenas y medias vallas Las medias vallas pueden garantizar semánticas de adquisición (lectura volátil) o semánticas de publicación (escritura volátil), pero no ambas al mismo tiempo. Una valla completa (a través de Thread.MemoryBarrier por ejemplo) garantiza ambos.
4.Interloked realiza una lectura/modificación/escritura en una operación atómica . ¿Se asegura el enclavamiento que está, por ejemplo, incrementando la última versión de una variable y las otras CPU verán este cambio? I creo que porque se supone que debe usar una barrera de memoria, pero no estoy seguro. Entonces, ¿ podríamos decir que Interloked está haciendo a Volátil leer/modificar/VolatileWrite atómicamente?
Yep. Y por lo que vale la pena, las operaciones de incrementos y decrementos entrelazados se pueden implementar con una operación CAS. En .NET usaría el método Interlocked.CompareExchange en un bucle hasta que la operación tuviera éxito. Apuesto a que los métodos Interlocked.Increment y Interlocked.Decrement usan una instrucción de CPU nativa, pero estoy preparado para estar equivocado al respecto.
5. Cuando utiliza una barrera de memoria, ¿afecta a todas las variables en todo CPUS, o solo a las que le rodean?
Afectará todos los accesos a la memoria, pero solo en la CPU que ejecuta esa secuencia.
6.Locking es caro, ya que causa dos barreras de memoria y un "cambio de contexto" si el hilo tiene que espera, pero entonces ¿cuál es la ventaja de Interlocked? solo para evitar el "cambio de contexto" ?
Sí, básicamente. El hilo nunca se bloquea con operaciones entrelazadas.
7. ¿Cuál es el trato con ReaderWriterLockSlim y la recursividad? No entendí cuál es el problema.
No puede adquirir el candado dos veces en el mismo hilo sin antes soltarlo. Hay más información en Joe Duffy's blog.
Estas son preguntas geniales, pero deben pedirse como publicaciones separadas. Sugiero eliminar esta publicación y dividirla en varias publicaciones más pequeñas. – jason
Supongo que debería explicar en detalle por qué: 1. Las publicaciones largas desalientan a los lectores a terminar (por lo que elimina los posibles contestadores). 2. Alguien que emigra conoce la respuesta a una de estas preguntas, pero no todas, y siente que no debe publicar una respuesta incompleta (para que elimine más respuestas). 3. Las preguntas largas con muchas preguntas toman mucho tiempo para responder (por lo que desaconseja incluso más respuestas). Obtendrá mejores y más respuestas si rompe esta publicación. – jason
Perdón por los errores tipográficos en los anteriores; reemplace "migrar saber el answe" para "saber la respuesta". – jason