Pregunta ¿Cómo pueden los compiladores C ++ soportar C ++ 11 atómico, pero no son compatibles con el modelo de memoria C ++ 11?


Al observar el estado de implementación de Clang y g ++ C ++ 11 noté algo extraño:
son compatibles con C ++ 11 atómica, pero no son compatibles con C ++ 11 modelo de memoria.
Estaba bajo la impresión de que debe tener el modelo de memoria C ++ 11 para usar átomos. Entonces, ¿cuál es exactamente la diferencia entre el soporte para atómico y el modelo de memoria?
¿La falta de compatibilidad con el modelo de memoria significa que los programas legales de C ++ 11 que usan std::atomic<T> ¿no es consecuente?

referencias:
http://clang.llvm.org/cxx_status.html
http://gcc.gnu.org/gcc-4.7/cxx0x_status.html


32
2017-07-02 12:40


origen


Respuestas:


Uno de los problemas es la definición de "ubicación de la memoria", que permite (y obliga al compilador a admitir) el bloqueo de diferentes miembros de la estructura por diferentes bloqueos. Hay un discusión sobre un problema de RL causado por este.

Básicamente, el problema es que tener un struct definido así:

struct x {
    long a;
    unsigned int b1;
    unsigned int b2:1;
};

el compilador es libre de implementar la escritura en b2 sobrescribiendo b1 también (y aparentemente, a juzgar por el informe, sí). Por lo tanto, los dos campos deben estar bloqueados como uno. Sin embargo, como consecuencia del modelo de memoria C ++ 11, esto está prohibido (bueno, no está realmente prohibido, pero el compilador debe garantizar actualizaciones simultáneas a b1 y b2 No interfieras; podría hacerlo bloqueando o cargando cada actualización, bueno, la vida es difícil en algunas arquitecturas). Citando del informe:

He planteado el problema con nuestros chicos de GCC y me dijeron que: "C lo hace   no proporciona dicha garantía, ni puede bloquear de manera confiable diferentes   campos de estructura con diferentes bloqueos si comparten naturalmente alineados   regiones de memoria de tamaño de palabra. El modelo de memoria C ++ 11 garantizaría esto,   pero eso no está implementado ni construyes el kernel con C ++ 11   compilador."

Buena información también se puede encontrar en el wiki.


15
2017-07-06 09:43



Supongo que el "Modelo de falta de memoria" en estos casos solo significa que los optimizadores se escribieron antes de que se publicara el modelo de memoria C ++ 11, y podrían realizar ahora optimizaciones no válidas. Es muy difícil y lleva mucho tiempo validar las optimizaciones en comparación con el modelo de memoria, por lo que no es una gran sorpresa que los equipos clang / gcc aún no hayan terminado.

¿La falta de compatibilidad con el modelo de memoria significa que los programas legales de C ++ 11 que usan std :: atomic no son consecuentes?

Sí, esa es una posibilidad. Es incluso peor: el compilador podría introducir carreras de datos en (de acuerdo con el estándar C ++ 11) los programas libres de raza, p. introduciendo escrituras especulativas.

Por ejemplo, varios compiladores de C ++ utilizados para realizar esta optimización:

for (p = q; p = p -> next; ++p) {
    if (p -> data > 0) ++count;
}

Podría ser optimizado en:

register int r1 = count;
for (p = q; p = p -> next; ++p) {
    if (p -> data > 0) ++r1;
}
count = r1;

Me caigo p->data son no negativos, el código fuente original no se escribió count, pero el código optimizado sí. Esto puede introducir una carrera de datos en un programa sin carreras, por lo que la especificación C ++ 11 no permite dichas optimizaciones. Los compiladores existentes ahora deben verificar (y ajustar si es necesario) todas las optimizaciones.

Ver Concurrencia de las consecuencias del compilador del modelo de memoria para detalles.


11
2017-07-03 17:12



No es tanto que no sean compatibles con el modelo de memoria, sino que no (todavía) admiten la API en el estándar para interactuar con el modelo de memoria. Esa API incluye una cantidad de mutexes.

Sin embargo, tanto Clang como GCC han sido tan conscientes de los hilos como es posible sin un estándar formal por algún tiempo. No tiene que preocuparse por las optimizaciones moviendo las cosas al lado equivocado de las operaciones atómicas.


0
2017-07-02 18:55