Te recomendamos que pruebes esta resolución en un entorno controlado antes de enviarlo a producción, un saludo.
Solución:
Para obtener la respuesta final y definitiva a esta pregunta, vaya directamente a la sección a continuación titulada “respuesta final a mi pregunta“.
ACTUALIZACIÓN 30 de octubre de 2018: Accidentalmente estaba haciendo referencia a los documentos (ligeramente) incorrectos (pero que decían exactamente lo mismo), así que los arreglé en mi respuesta aquí. Consulte “Notas sobre los cambios del 30 de octubre de 2018” al final de esta respuesta para obtener más detalles.
Definitivamente no entiendo cada palabra aquí, pero el Manual de referencia de la arquitectura ARM v7-M (Fuente en línea; descarga directa del archivo PDF) (NO el Manual de referencia técnica [TRM]ya que no discute la atomicidad) valida mis suposiciones:
Entonces… creo que mis 7 suposiciones en la parte inferior de mi pregunta son todas correctas. [30 Oct. 2018: Yes, that is correct. See below for details.]
ACTUALIZACIÓN 29 de octubre de 2018:
Un pequeño dato más:
Richard Barry, fundador, experto y desarrollador central de FreeRTOS, afirma en tasks.c…
/* No se requiere una sección crítica porque las variables son de tipo BaseType_t. */
…al leer una variable volátil “larga sin firmar” (4 bytes) en STM32. Esto significa que él, al menos, está 100% seguro de que las lecturas y escrituras de 4 bytes son atómicas en STM32. No menciona lecturas de bytes más pequeños, pero para lecturas de 4 bytes está completamente seguro. Tengo que suponer que las variables de 4 bytes que son el ancho del procesador nativo y también, alineadas con palabras, son críticas para que esto sea true.
Desde tasks.clíneas 2173-2178 en FreeRTOS v9.0.0, por ejemplo:
UBaseType_t uxTaskGetNumberOfTasks( void )
/* A critical section is not required because the variables are of type
BaseType_t. */
return uxCurrentNumberOfTasks;
Él usa esta frase exacta de…
/* No se requiere una sección crítica porque las variables son de tipo BaseType_t. */
…en dos ubicaciones diferentes en este archivo.
Respuesta final a mi pregunta: todos los tipos <= 4 bytes (todos en negrita tipos en la lista de 9 filas a continuación) son atómicos.
Además, luego de una inspección más cercana del TRM en p141 como se muestra en mi captura de pantalla anterior, el key Las oraciones que me gustaría señalar son:
En ARMv7-M, el atómico de una sola copia Los accesos al procesador son:
• todos byte accesos
• todos media palabra accesos a ubicaciones alineadas con media palabra.
• todos palabra accesos a ubicaciones alineadas con palabras.
Y, según este enlace, lo siguiente es true para “tipos de datos básicos implementados en ARM C y C++” (es decir, en STM32):
bool/_Boolestá “alineado con bytes” (alineado con 1 byte)int8_t/uint8_testá “alineado con bytes” (alineado con 1 byte)int16_t/uint16_testá “alineado con media palabra” (alineado con 2 bytes)int32_t/uint32_testá “alineado con palabras” (alineado con 4 bytes)int64_t/uint64_testá “alineado con palabra doble” (alineado con 8 bytes) <-- NO GARANTIZADO ATOMICfloatestá “alineado con palabras” (alineado con 4 bytes)doubleestá “alineado con palabra doble” (alineado con 8 bytes) <-- NO GARANTIZADO ATOMIClong doubleestá “alineado con palabra doble” (alineado con 8 bytes) <-- NO GARANTIZADO ATOMIC- todos los punteros están “alineados con palabras” (alineados con 4 bytes)
Esto significa que ahora tengo y entiendo la evidencia que necesito para afirmar de manera concluyente que todas las filas en negrita justo arriba tienen acceso atómico automático de lectura y escritura (pero NO incremento/decremento, por supuesto, que son operaciones múltiples). Esta es la respuesta final a mi pregunta.Creo que la única excepción a esta atomicidad podría ser en las estructuras empaquetadas, en cuyo caso estos tipos de datos alineados naturalmente pueden no estar alineados naturalmente.
También tenga en cuenta que al leer el Manual de referencia técnica, “atomicidad de copia única” aparentemente solo significa “atomicidad de CPU de un solo núcleo” o “atomicidad en una arquitectura de núcleo de CPU único”. Esto contrasta con la “atomicidad de copias múltiples”, que se refiere a un “sistema de procesamiento múltiple” o arquitectura de CPU de múltiples núcleos. Wikipedia afirma que “el multiprocesamiento es el uso de dos o más unidades centrales de procesamiento (CPU) dentro de un solo sistema informático” (https://en.wikipedia.org/wiki/Multiprocessing).
Mi arquitectura en cuestión, STM32F767ZI (con núcleo ARM Cortex-M7), es una arquitectura de un solo núcleo, por lo que aparentemente se aplica la “atomicidad de copia única”, como he citado anteriormente del TRM.
Otras lecturas:
- ARM: ¿Escribir/leer desde int es atómico?
- ¿Cuál es la diferencia entre atómico / volátil / sincronizado?
- ¿Se pueden leer atómicamente las variables dentro de las estructuras empaquetadas?
Notas sobre los cambios del 30 de octubre de 2018:
- Tenía esta referencia: ARMv7 TRM (Manual de referencia técnica). Sin embargo, esto está mal de 2 maneras: 1) ¡Esto no es un TRM en absoluto! El TRM es un manual de referencia técnica breve (~200 páginas). Este, sin embargo, es el “Manual de referencia de arquitectura”, NO el TRM. Es un documento mucho más largo y más genérico, ya que los manuales de referencia de Arquitectura son del orden de ~1000~2000 páginas. 2) Esto es para los procesadores ARMv7-A y ARMv7-R, pero el manual que necesito para el mcu STM32 en cuestión es para el procesador ARMv7-M.
- Aquí está el enlace correcto al Manual de referencia técnica del procesador ARM Cortex-M7. En línea: https://developer.arm.com/docs/ddi0489/latest. PDF: https://static.docs.arm.com/ddi0489/d/DDI0489D_cortex_m7_trm.pdf.
- El TRM correcto justo arriba, en la página 99 (5-36), dice: “Para obtener más información sobre la atomicidad, consulte el Manual de referencia de la arquitectura ARM®v7-M”. Entonces, aquí está ese manual. Enlace de descarga en línea: https://developer.arm.com/products/architecture/cpu-architecture/m-profile/docs/ddi0403/latest/armv7-m-architecture-reference-manual. PDF: https://static.docs.arm.com/ddi0489/d/DDI0489D_cortex_m7_trm.pdf. Discute la atomicidad en p79-80 (A3-79 a A3-80).
Reseñas y calificaciones del post
Si para ti ha sido de provecho nuestro artículo, sería de mucha ayuda si lo compartes con el resto entusiastas de la programación y nos ayudes a extender esta información.