Lines Matching refs:que
37 sus maintainers en lugar de que como un oráculo infalible.
39 De nuevo, este documento no es una especificación de lo que Linux espera
44 (1) especificar la funcionalidad mínima en la que se puede confiar para
49 Tenga en cuenta que una arquitectura puede proporcionar más que el
53 Tenga en cuenta también que es posible que una barrera no valga (sea no-op)
54 para alguna arquitectura porque por la forma en que funcione dicha
110 (*) Cosas que hacen las CPU.
151 Cada CPU ejecuta un programa que genera operaciones de acceso a la memoria.
154 en el orden que desee, siempre que la causalidad del programa parezca
156 instrucciones que emite en el orden que quiera, siempre que no afecte al
161 medida que las operaciones cruzan la interfaz entre la CPU y el resto del
196 que fueron realizados.
206 Aquí hay una dependencia obvia de la dirección, ya que el valor cargado en
214 Tenga en cuenta que la CPU 2 nunca intentará cargar C en D porque la CPU
221 de ubicaciones de memoria, pero el orden en que se accede a los registros
223 un conjunto de registros a los que se accede a través de un registro de
236 ya que se estableció la dirección _después_ de intentar leer el registro.
242 Hay algunas garantías mínimas que se pueden esperar de una CPU:
245 emitirán en orden, con respeto a sí mismo. Esto significa que para:
255 emite una instrucción de barrera de memoria, de modo que una CPU DEC
260 Ya sea en DEC Alpha o no, READ_ONCE() también evita que el compilador
264 parecerán ser ordenados dentro de esa CPU. Esto significa que para:
284 Y hay una serie de cosas que _deben_ o _no_ deben asumirse:
286 (*) _No_debe_ asumirse que el compilador hará lo que usted quiera
287 con referencias de memoria que no están protegidas por READ_ONCE() y
289 de transformaciones "creativas", que se tratan en la sección BARRERA
292 (*) _No_debe_ suponerse que se emitirán loads y stores independientes
293 en el orden dado. Esto significa que para:
306 (*) Se _debe_ suponer que los accesos de memoria superpuestos pueden
307 fusionarse o ser descartados. Esto significa que para:
334 (*) Incluso en los casos en que los campos de bits están protegidos por
343 dimensionados. De "tamaño adecuado" significa actualmente variables que
344 son del mismo tamaño que "char", "short", "int" y "long".
349 en cuenta que estos garantías se introdujeron en el estándar C11, así
350 que tenga cuidado cuando utilice compiladores anteriores a C11 (por
351 ejemplo, gcc 4.6). La parte de la norma que contiene esta garantía es
352 la Sección 3.14, que define "ubicación de memoria" de la siguiente
363 NOTE 2: Un campo de bits y un miembro adyacente que no es un campo de
380 problema para la interacción CPU-CPU y para la E/S ("I/O"). Lo que se
393 utilizan para anular o suprimir estos trucos, permitiendo que el código
405 Una barrera de memoria de escritura garantiza que todas las
406 operaciones de STORE especificadas antes de que la barrera aparezca
411 es requerido que tenga ningún efecto sobre los loads.
413 Se puede considerar que una CPU envía una secuencia de operaciones de
414 store al sistema de memoria a medida que pasa el tiempo. Todos los
418 [!] Tenga en cuenta que las barreras de escritura normalmente deben
427 barrera de lectura. En el caso de que se realicen dos loads de manera
428 que la segunda dependa del resultado de la primera (por ejemplo: el
429 primer load recupera la dirección a la que se dirigirá el segundo
431 asegurarse de que el objetivo de la segunda carga esté actualizado
435 laods de direcciones interdependientes; no se requiere que tenga
440 secuencias de stores en el sistema de memoria que la considerada CPU
442 la CPU en cuestión garantiza que para cualquier carga que la preceda,
444 en el momento en que la barrera se complete, los efectos de todos los
451 [!] Tenga en cuenta que la primera carga realmente tiene que tener una
459 [!] Tenga en cuenta que las barreras de dependencia de dirección
472 más una garantía de que todas las operaciones de LOAD especificadas
478 necesario que tenga ningún efecto en los stores.
483 [!] Tenga en mente que las barreras de lectura normalmente deben
489 Una barrera de memoria general proporciona la garantía de que todas
490 las operaciones LOAD y STORE especificadas antes de que la barrera
491 aparezca suceden antes de que todas las operaciones LOAD y STORE
499 de lectura como de escritura, de modo que pueden sustituir a
506 Esto actúa como una barrera permeable unidireccional. Garantiza que
512 Las operaciones de memoria que ocurren antes de una operación ACQUIRE
513 pueden parecer suceder después de que se complete.
522 Garantiza que todas las operaciones de memoria antes de la operación
527 Las operaciones de memoria que ocurren después de una operación
528 RELEASE pueden parecer suceder antes de que se complete.
534 todos los accesos a la memoria que preceden a cualquier anterior
540 Esto significa que ACQUIRE actúa como una operación mínima de
547 composiciones atómicas que realizan tanto un load como store, la semántica
553 garantizar que no habrá tal interacción en ninguna pieza de código en
557 Tenga en cuenta que estas son las garantías _mínimas_. Diferentes
565 Hay ciertas cosas que las barreras de memoria del kernel Linux no
568 (*) No hay garantía de que ninguno de los accesos a la memoria
571 que la barrera dibuja una línea en la cola de acceso del CPU que no
574 (*) No hay garantía de que la emisión de una barrera de memoria en una CPU
576 en el sistema. El efecto indirecto será el orden en que la segunda CPU
577 ve los efectos de los primeros accesos que ocurren de la CPU, pero lea
580 (*) No hay garantía de que una CPU vea el orden correcto de los efectos
582 barrera de memoria, a menos que la primera CPU _también_ use una
586 (*) No hay garantía de que alguna pieza intermedia fuera del hardware[*]
589 una barrera de memoria entre las CPU, pero es posible que no lo hagan
603 READ_ONCE() para DEC Alpha, lo que significa que las únicas personas que
604 necesitan prestar atención a esta sección son aquellas que trabajan en el
605 código específico de la arquitectura DEC Alpha y aquellas que trabajan en
606 READ_ONCE() por dentro. Para aquellos que lo necesitan, y para aquellos que
615 y no siempre es obvio que sean necesarias. Para ilustrar, considere la
628 que no implica una barrera de dependencia de direcciones.
630 Hay una clara dependencia de dirección aquí, y parecería que al final de
631 la secuencia, Q debe ser &A o &B, y que:
662 [!] Tenga en cuenta que esta situación extremadamente contraria a la
664 que, por ejemplo, un banco de caché procesa líneas de caché pares y el otro
668 caché de la CPU de lectura está extremadamente ocupado mientras que el
674 escrituras dependientes porque las CPU que admite el kernel Linux no
675 escriben hasta que están seguros (1) de que la escritura realmente
697 Tenga en cuenta que este patrón debe ser raro. Después de todo, el objetivo
701 de error y similares, y el orden natural de las CPUs evita que se pierdan
705 Tenga en cuenta que el orden proporcionado por una dependencia de dirección
706 es local para la CPU que lo contiene. Lea la sección sobre "Atomicidad
712 include/linux/rcupdate.h. Esto permite que el objetivo actual de un puntero
713 RCU sea reemplazado con un nuevo objetivo modificado, sin que el objetivo
724 ayudarle a prevenir que la ignorancia del compilador rompa su código.
728 (implícita) de dependencia de direcciones para que funcione correctamente.
739 real, sino más bien una dependencia de control que la CPU puede
740 cortocircuitar al intentar predecir el resultado por adelantado, para que
741 otras CPU vean la carga de b como si hubiera ocurrido antes que la carga de
742 a. En cuyo caso lo que realmente se requiere es:
750 Sin embargo, los stores no se especulan. Esto significa que ordenar -es-
760 barreras. Dicho esto, tenga en cuenta que ni READ_ONCE() ni WRITE_ONCE()
766 Peor aún, si el compilador puede probar (decir) que el valor de la
773 Así que no deje de lado READ_ONCE().
803 Ahora no hay condicional entre la carga de 'a' y el store de 'b', lo que
804 significa que la CPU está en su derecho de reordenarlos: El condicional es
806 incluso después de que se hayan aplicado todas las optimizaciones del
833 Aún se requiere el inicial READ_ONCE() para evitar que el compilador toque
836 Además, debe tener cuidado con lo que hace con la variable local 'q', de lo
849 Si MAX se define como 1, entonces el compilador sabe que (q % MAX) es igual
861 asegurarse de que MAX sea mayor que uno, tal vez de la siguiente manera:
873 Tenga en cuenta una vez más que los stores de 'b' difieren. Si fueran
884 Debido a que la primera condición no puede fallar y la segunda condición es
891 Este ejemplo subraya la necesidad de asegurarse de que el compilador no
898 aplica necesariamente al código que sigue a la declaración if:
908 Es tentador argumentar que, de hecho, existe un orden porque el compilador
927 las funciones invocado por esas dos cláusulas), no al código que sigue a
931 Tenga muy en cuenta que el orden proporcionado por una dependencia de
932 control es local a la CPU que lo contiene. Vea el apartado de "Atomicidad
948 smp_store_release() para realizar el store. Tenga en cuenta que -no-
961 (*) Las dependencias de control requieren que el compilador evite
968 cláusula else de la sentencia "if" que contiene la dependencia de
969 control, incluyendo cualquier función a la que llamen dichas dos
970 cláusulas. Las dependencias de control no se aplican al código que
971 sigue a la instrucción if que contiene la dependencia de control.
981 tanto es su trabajo asegurarse de que no rompan su código.
1034 Básicamente, la barrera de lectura siempre tiene que estar ahí, aunque
1037 [!] Tenga en cuenta que normalmente se esperaría que los stores antes de la
1066 de memoria en un orden que el resto del sistema podría percibir como el
1080 | | +------+ } escritura requiere que todos los
1082 | | : +------+ } sean confirmados antes de que otros
1136 En el ejemplo anterior, la CPU 2 percibe que B es 7, a pesar de la carga de
1137 *C (que sería B) viniendo después del LOAD de C.
1173 Se asegura de que ---> \ aaaaaaaaaaaaaaaaa | |
1246 de lectura consigue que \ +-------+ | |
1252 Para ilustrar esto de manera más completa, considere lo que podría pasar si
1286 de lectura consigue que \ +-------+ | |
1291 Pero puede ser que la actualización a A desde la CPU 1 se vuelva
1292 perceptible para la CPU 2 antes de que la barrera de lectura se complete de
1317 La garantía es que la segunda carga siempre dará como resultado A == 1 si
1325 Muchas CPU especulan con las cargas: es decir, ven que necesitarán cargar
1326 un elemento de la memoria, y encuentran un momento en el que no están
1329 de instrucciones todavía. Esto permite que la instrucción de carga real
1333 Puede resultar que la CPU en realidad no necesitara el valor, tal vez
1426 orden que no es siempre proporcionada por los sistemas informáticos reales,
1427 a saber, que un determinada store se vuelve visible al mismo tiempo para
1428 todos las CPU o, alternativamente, que todas las CPU acuerdan el orden en
1429 que todos los stores se vuelven visibles. Sin embargo, el soporte para
1431 hardware, por lo que una versión más débil conocida como ``otra atomicidad
1432 multicopia'' en cambio, solo garantiza que un store dado se vuelva visible
1446 Suponga que la carga de la CPU 2 desde X devuelve 1, que luego almacena en
1447 Y, y la carga de la CPU 3 desde Y devuelve 1. Esto indica que el store de
1450 garantizan que la CPU 2 ejecuta su carga antes que su almacenamiento, y la
1454 Debido a que la carga de la CPU 3 desde X en cierto sentido viene después
1455 de la carga de la CPU 2, es natural esperar que la carga de la CPU 3 desde
1457 si una carga que se ejecuta en la CPU B sigue una carga de la misma
1458 variable que se ejecuta en la CPU A (y la CPU A no almacenó originalmente
1459 el valor que leyó), entonces en sistemas atómicos multicopia, la carga de
1460 la CPU B debe devolver el mismo valor que hizo la carga de la CPU A o algún
1461 valor posterior. Sin embargo, el kernel Linux no requiere que los sistemas
1471 Por ejemplo, supongamos que la barrera general de la CPU 2 se elimina del
1472 ejemplo anterior, dejando solo la dependencia de datos que se muestra a
1482 Esta sustitución permite que la atomicidad no multicopia se desenfrene: en
1483 este ejemplo, es perfectamente legal que la carga de la CPU 2 desde X
1487 El punto clave es que aunque la dependencia de datos de la CPU 2 ordena su
1488 carga y store, no garantiza ordenar el store de la CPU 1. De forma que, si
1492 requieren barreras generales para garantizar que todas las CPU acurden el
1496 multicopia, pero también pueden generar orden adicional que puede asegurar
1497 que -todas- las CPU percibirán el mismo orden de -todas- las operaciones.
1499 proporciona este orden adicional, lo que significa que solo se garantiza
1500 que las CPU de la cadena estén de acuerdo en el orden combinado de los
1534 Dado que cpu0(), cpu1() y cpu2() participan en una cadena de parejas
1541 cpu1() debe ver las escrituras de cpu0(), de modo que el siguiente
1547 liberación-adquisición es local a las CPU que participan en esa cadena y no
1558 en orden, las CPU que no participan en la cadena de liberación-adquisición
1560 de que las instrucciones de barrera de memoria débiles utilizadas para
1563 Esto significa que cpu3() puede ver el store de cpu0() suceder -después- de
1565 acuerdo en que estas dos operaciones ocurrieron en el orden previsto.
1567 Sin embargo, tenga en cuenta que smp_load_acquire() no es mágico. En
1569 asegura que se leerá cualquier valor en particular. Por lo tanto, los
1574 Tenga en cuenta que este resultado puede ocurrir incluso en un mítico
1585 El kernel Linux tiene una variedad de diferentes barreras que actúan a
1597 que evita que el el compilador mueva los accesos a la memoria de cualquier
1604 WRITE_ONCE() pueden ser considerado como formas débiles de barrier() que
1609 (*) Evita que el compilador reordene los accesos tras barrier() para
1610 preceder a cualquier acceso que preceda a barrier(). Un ejemplo de uso
1613 que fue interrumpido.
1620 de optimizaciones que, si bien son perfectamente seguras en código de un
1626 derecho de reordenar cargas a la misma variable. Esto significa que
1632 Podría resultar en un valor más antiguo de x almacenado en a[1] que en
1633 a[0]. Evite que tanto el compilador como la CPU hagan esto de la
1643 variable. Tal fusión puede hacer que el compilador "optimice" el
1649 en el siguiente código, que, aunque en cierto sentido es legítimo
1650 para un código de un solo subproceso, es casi seguro que no es lo
1651 que el desarrollador pretendía:
1657 Use READ_ONCE() para evitar que el compilador le haga esto:
1663 en los casos en que la alta presión de los registros impida que el
1671 Esto podría resultar en el siguiente código, que es perfectamente
1679 pasar un cero a hacer_algo_con() en el caso de que la variable a sea
1683 De nuevo, use READ_ONCE() para evitar que el compilador haga esto:
1688 Tenga en cuenta que si el compilador se queda sin registros, podría
1690 este guardado y posterior restauración es por lo que los compiladores
1692 subproceso único, por lo que debe informar al compilador sobre los
1697 que el valor de la variable 'a' siempre es cero, puede optimizar este
1709 que el compilador llevará a cabo su prueba asumiendo que la CPU actual
1712 READ_ONCE() para decirle al compilador que no sabe tanto como cree:
1717 Pero, por favor, tenga en cuenta que el compilador también está
1718 observando de cerca lo que usted hace con el valor después de
1719 READ_ONCE(). Por ejemplo, suponga que Ud. hace lo siguiente y MAX es
1725 Entonces el compilador sabe que el resultado del operador "%" aplicado
1726 a MAX siempre será cero, nuevamente permitiendo que el compilador
1731 completo si sabe que la variable ya tiene el valor almacenado.
1732 Nuevamente, el compilador asume que la CPU actual es la única que
1733 almacena la variable, lo que puede hacer que el compilador haga
1735 que tiene lo siguiente:
1738 ... Código que no almacena la variable a ...
1741 El compilador observa que el valor de la variable 'a' ya es cero, por
1742 lo que bien podría omitir el segundo store. Esto supondría una fatal
1746 Use WRITE_ONCE() para evitar que el compilador haga este tipo de
1750 ... Código que no almacena la variable a ...
1754 que le diga que no. Por ejemplo, considere la siguiente interacción
1769 No hay nada que impida que el compilador transforme
1770 nivel_de_procesamiento() a lo siguiente, que de hecho, bien podría ser
1795 Tenga en cuenta que los envoltorios ("wrappers") READ_ONCE() y
1797 controlador de interrupciones puede ser interrumpido por algo que
1801 documentación. (Tenga también en cuenta que las interrupciones
1806 Debe suponer que el compilador puede mover READ_ONCE() y WRITE_ONCE()
1807 a código que no contiene READ_ONCE(), WRITE_ONCE(), barrier(), o
1813 memoria indicadas, mientras que con barrier() el compilador debe
1814 descartar el valor de todas las ubicaciones de memoria que tiene
1816 Por supuesto, el compilador también debe respetar el orden en que
1835 En el código de un solo subproceso, esto no solo es seguro, sino que
1837 esta optimización podría causar que alguna otra CPU vea un valor falso
1855 tearing), en el que un solo gran acceso es reemplazado por múltiples
1856 accesos menores. Por ejemplo, dada una arquitectura que tiene
1864 Tenga en cuenta que GCC realmente usa este tipo de optimización, lo
1865 cual no es sorprendente dado que probablemente costaría más de dos
1868 solo subproceso. De hecho, un error reciente (desde que se solucionó)
1869 hizo que GCC usara incorrectamente esta optimización en un store
1885 Debido a que no hay envoltorios READ_ONCE() o WRITE_ONCE() y no
1898 variable que se ha marcado como volátil. Por ejemplo, dado que 'jiffies'
1900 razón de esto es que READ_ONCE() y WRITE_ONCE() se implementan como
1901 conversiones volátiles, lo que no tiene efecto cuando su argumento ya está
1904 Tenga en cuenta que estas barreras del compilador no tienen un efecto
1905 directo en la CPU, que luego puede reordenar las cosas como quiera.
1925 Además: en el caso de las dependencias de direcciones, se esperaría que el
1927 tendría que cargar el valor de b antes de cargar a[b]), sin embargo, no hay
1928 garantía alguna en la especificación de C sobre que el compilador no puede
1929 especular el valor de b (por ejemplo, es igual a 1) y carga a[b] antes que
1931 que un compilador vuelva a cargar b después de haber cargado a[b], teniendo
1932 así una copia más nueva de b que a[b]. Aún no se ha conseguido un consenso
1937 compila a monoprocesador, porque se supone que una CPU parecerá ser
1942 [!] Tenga en cuenta que las barreras de memoria SMP _deben_ usarse para
1947 SMP, ya que dichas barreras imponen una sobrecarga innecesaria en los
1950 barreras son necesarias incluso en sistemas que no son SMP, ya que afectan
1951 al orden en que las operaciones de memoria aparecen en un dispositivo, al
1952 prohibir tanto al compilador como a la CPU que sean reordenados.
1960 completa después de ella. No se garantiza insertar nada más que una
1967 Estos se pueden usar con funciones RMW atómicas que no implican
1969 memoria. Ejemplos de funciones RMW atómicas que no implican una
1975 Estos también se utilizan para funciones atómicas RMW bitop que no
1978 Como ejemplo, considere una pieza de código que marca un objeto como
1985 Esto asegura que la marca de muerte en el objeto se perciba como
1986 fijada *antes* de que disminuya el contador de referencia.
2000 Por ejemplo, considere un controlador de dispositivo que comparte
2007 /* no leer los datos hasta que tengamos el descriptor */
2024 El dma_rmb() nos permite garantizar que el dispositivo ha liberado su
2025 propiedad antes de que leamos los datos del descriptor, y el dma_wmb()
2026 permite garantizar que los datos se escriben en el descriptor antes de
2027 que el dispositivo pueda ver que ahora tiene la propiedad. El dma_mb()
2028 implica tanto un dma_rmb() como un dma_wmb(). Tenga en cuenta que, al
2029 usar writel(), no se necesita un wmb() anterior para garantizar que
2041 Es es para uso con memoria persistente para garantizar que los stores
2042 para los que las modificaciones se escriben en el almacenamiento
2046 usamos pmem_wmb() para garantizar que los stores hayan alcanzado el
2047 dominio de durabilidad de la plataforma. Esto garantiza que los stores
2059 ejemplo, los devueltos por ioremap_wc(), la CPU puede esperar a que
2096 después de que la operación ACQUIRE haya finalizado.
2099 completarse después que la operación ACQUIRE se ha completado.
2104 completarán antes de que la operación de RELEASE se haya completado.
2107 completarse antes de que la operación de RELEASE se haya completado.
2122 sea debido a no poder obtener el bloqueo de inmediato, o debido a que
2123 recibieron una señal de desbloqueo mientras dormían esperando que el
2127 [!] Nota: una de las consecuencias de que los cerrojos en ACQUIRE y RELEASE
2128 sean barreras unidireccionales, es que los efectos de las instrucciones
2132 No se puede suponer que un ACQUIRE seguido de una RELEASE sea una barrera
2133 de memoria completa dado que es posible que un acceso anterior a ACQUIRE
2149 perspectiva de otra CPU que no tiene ese bloqueo. En resumen, un ACQUIRE
2156 pueden cruzarse, de modo que:
2167 Podría parecer que este nuevo orden podría introducir un punto muerto.
2174 Un punto clave es que solo estamos hablando de la CPU re-haciendo el
2178 Pero supongamos que la CPU reordenó las operaciones. En este caso, el
2183 CPU eventualmente ejecutará la operación de desbloqueo (que precedió a la
2184 operación de bloqueo en el código ensamblador), lo que desenmascará el
2185 potencial punto muerto, permitiendo que la operación de bloqueo tenga
2188 Pero, ¿y si el cerrojo es un cerrojo que duerme ("sleeplock")? En tal
2190 encontrará una barrera de memoria, que forzará la operación de desbloqueo
2196 Es posible que los cerrojos y los semáforos no proporcionen ninguna
2197 garantía de orden en sistemas compilados en UP, por lo que no se puede
2199 especialmente con respecto a los accesos de E/S, a menos que se combinen
2220 [+] Tenga en cuenta que {*F,*A} indica un acceso combinado.
2234 Las funciones que deshabilitan interrupciones (equivalentes a ACQUIRE) y
2244 que se pueden ver como una interacción entre dos piezas de datos: el estado
2245 de la task (hilo, proceso, tarea) que espera el evento y los datos globales
2246 utilizados para indicar el evento. Para asegurarse de que estos parezcan
2277 que por lo tanto también implican una barrera de memoria general después de
2292 En segundo lugar, el código que realiza una activación normalmente se
2318 donde "task" es el subproceso que se está despertando y es igual al
2337 barrera, de nuevo, ocurre antes de que se acceda al estado del hilo. En
2360 mismas garantías que un wake_up() (o más fuertes).
2362 [!] Tenga en cuenta que las barreras de la memoria implicadas por el
2364 respecto a cargas de los valores guardados después de que el durmiente haya
2373 y el que despierta hace:
2379 no existe garantía de que el cambio a event_indicated sea percibido por
2380 el durmiente de manera que venga después del cambio a my_data. En tal
2391 y el que despierta debería hacer:
2401 Otras funciones que implican barreras:
2411 sustancial de barrera: una que afecta el orden de acceso a la memoria en
2432 hasta que *H ocurra, además de las restricciones impuestas por los bloqueos
2449 generalmente no va a suponer un problema, ya que para una pieza de código
2450 lineal de un solo subproceso seguirá pareciendo que funciona correctamente,
2452 circunstancias en las que reordenar definitivamente _podría_ ser un
2471 bastante caros, por lo que puede ser preferible operar sin el uso de un
2472 cerrojo a ser posible. En cuyo caso, es posible que las operaciones que
2477 de espera en cola del semáforo, en virtud de que tiene una parte de su pila
2491 Para despertar a un proceso que espera ("waiter") en particular, las
2492 funciones up_read() o up_write() tienen que:
2494 (1) leer el siguiente puntero del registro de este proceso que espera,
2499 (3) borrar el puntero de la tarea para decirle al waiter que se le ha dado
2506 En otras palabras, tiene que realizar esta secuencia de eventos:
2514 y si alguno de estos pasos ocurre fuera de orden, entonces todo puede que
2517 Una vez que se ha puesto en cola y soltado el bloqueo de semáforo, el
2518 proceso que espera no consigue el candado de nuevo; en cambio, solo espera
2519 a que se borre su puntero de tarea antes de continuar. Dado que el registro
2520 está en la pila del proceso que espera, esto significa que si el puntero de
2521 la tarea se borra _antes_ de que se lea el siguiente puntero de la lista,
2522 otra CPU podría comenzar a procesar el proceso que espera y podría romper
2523 el stack del proceso que espera antes de que la función up*() tenga la
2524 oportunidad de leer el puntero que sigue.
2526 Considere entonces lo que podría suceder con la secuencia de eventos
2548 función down_xxx() tiene que obtener innecesariamente el spinlock
2560 En este caso, la barrera garantiza que todos los accesos a memoria antes de
2563 que todos los accesos a memoria antes de la barrera se completarán en el
2564 momento en que la instrucción de la barrera en sí se complete.
2567 solo una barrera del compilador, asegurándose así de que el compilador
2592 locales (una forma de bloqueo), de modo que las operaciones críticas sean
2595 es posible que el "core" del controlador no se ejecute en la misma CPU y no
2596 se permita que su interrupción vuelva a ocurrir hasta que la interrupción
2600 Sin embargo, considere un driver que estaba hablando con una tarjeta
2601 ethernet que tiene un registro de direcciones y un registro de datos. Si
2621 Si se relajan las reglas de orden, se debe asumir que los accesos
2624 interrupción - y viceversa - a menos que se utilicenn barreras implícita o
2629 registros E/S estrictamente ordenados, que forman barreras de E/S
2634 rutinas ejecutándose en separadas CPU que se comunican entre sí. Si tal
2645 que son inherentemente no portátiles pueden depender de comportamientos
2647 sincronización de la manera más ligera posible. Para drivers que deseen ser
2649 kernel ofrece una serie de funciones de acceso que proporcionan varios
2655 periférico al que se accede como un parámetro __iomem *. para punteros
2660 entre estos. Esto asegura que los registros de acceso MMIO por el
2664 2. Se ordena un writeX() emitido por un subproceso de CPU que contiene un
2667 mismo spinlock. Esto garantiza que ese registro MMIO escribe en un
2668 dispositivo en particular, mientras que se obtiene un spinlock en un
2674 que las escrituras de la CPU a un búfer DMA de salida asignadas por
2680 completará antes de que cualquier lectura subsiguiente de memoria por
2681 el mismo subproceso pueda comenzar. Esto asegura que las lecturas de
2684 registro de estado MMIO del motor DMA, para establecer que la
2688 completará antes de que cualquier bucle delay() subsiguiente pueda
2689 comenzar a ejecutarse en el mismo subproceso. Esto asegura que dos
2701 atributos que no sean los valores por defecto (por ejemplo, los devueltos
2711 delay() (es decir, los puntos 2-5 arriba) pero todavía se garantiza que
2719 acceder FIFOs mapeados en memoria y basados en registros que residen en
2720 periféricos, que no son capaces de realizar DMA. Por tanto, sólo
2727 de puertos "legacy" (antiguos) de periféricos de E/S, que pueden requerir
2729 x86). El número de puerto del periférico que se está accedido se pasa
2732 Dado que muchas arquitecturas de CPU acceden finalmente a estos
2735 mismas que las proporcionadas por readX() y writeX(), respectivamente, al
2737 predeterminados (los que haya por defecto).
2739 Los drivers de dispositivos pueden esperar que outX() emita una
2740 transacción de escritura no publicada, que espera una respuesta de
2753 Estos funcionarán adecuadamente para el tipo de acceso que realmente están
2757 writesX()), todo lo anterior supone que el periférico subyacente es
2766 Debe suponerse que la CPU conceptual está débilmente ordenada, pero que
2768 Algunas CPU (como i386 o x86_64) están más limitadas que otras (como
2769 powerpc o frv), por lo que el caso más relajado (es decir, DEC Alpha) se
2772 Esto significa que se debe considerar que la CPU ejecutará su flujo de
2773 instrucciones en el orden que se quiera - o incluso en paralelo - siempre
2774 que si una instrucción en el flujo depende de una instrucción anterior,
2776 antes de que la posterior instrucción puede proceder; en otras palabras:
2777 siempre que la apariencia de causalidad se mantenga.
2783 Una CPU puede también descartar cualquier secuencia de instrucciones que
2789 De manera similar, se debe suponer que el compilador podría reordenar la
2790 corriente de instrucciones de la manera que crea conveniente, nuevamente
2791 siempre que la apariencia de causalidad se mantenga.
2798 La forma en que se perciben las operaciones de memoria caché en todo el
2799 sistema se ve afectada, hasta cierto punto, por los cachés que se
2801 memoria que mantiene la consistencia de estado en el sistema.
2803 En cuanto a la forma en que una CPU interactúa con otra parte del sistema a
2804 través del caché, el sistema de memoria tiene que incluir los cachés de la
2805 CPU y barreras de memoria, que en su mayor parte actúan en la interfaz
2831 Aunque es posible que una carga o store en particular no aparezca fuera de
2832 la CPU que lo emitió, ya que puede haber sido satisfecha dentro del propio
2834 hubiera tenido lugar para las otras CPUs, ya que los mecanismos de
2835 coherencia de caché migrarán la cacheline sobre la CPU que accede y se
2838 El núcleo de la CPU puede ejecutar instrucciones en el orden que considere
2839 adecuado, siempre que parezca mantenerse la causalidad esperada del
2841 almacenamiento que luego van a la cola de accesos a memoria a realizar. El
2842 núcleo puede colocarlos en la cola en cualquier orden que desee, y
2843 continuar su ejecución hasta que se vea obligado a esperar que una
2846 De lo que se ocupan las barreras de la memoria es de controlar el orden en
2847 que los accesos cruzan, desde el lado de la CPU, hasta el lado de memoria,
2848 y el orden en que los otros observadores perciben los efectos en el sistema
2849 que sucedan por esto.
2852 determinada, ya que las CPU siempre ven sus propias cargas y stores como si
2858 instrucciones especiales de comunicación con dispositivo que pueda tener la
2866 dispositivos que realizan DMA. En tales casos, un dispositivo que intente
2868 "sucias" pueden residir en los cachés de varias CPU, y es posible que no
2874 sobrescritos por líneas de caché sucias que se escriben de nuevo en la RAM
2875 desde el caché de una CPU, después de que el dispositivo haya puesto sus
2877 simplemente ocultar el hecho de que la memoria RAM se haya actualizado,
2878 hasta el momento en que la caché se descarta de la memoria caché de la CPU
2890 ubicaciones de memoria que forman parte de una ventana del espacio de
2891 memoria de la CPU, que tiene diferentes propiedades asignadas que la
2894 Entre dichas propiedades, suele existir el hecho de que tales accesos
2896 buses del dispositivo. Esto significa que los accesos MMIO pueden, en
2897 efecto, superar los accesos a la memoria caché que se emitieron
2899 que el caché debe ser vaciado entre la escritura de la memoria caché, y el
2907 Un programador podría dar por sentado que la CPU realizará las operaciones
2908 de memoria exactamente en el orden especificado, de modo que si a la CPU se
2917 esperarían entonces que la CPU complete la operación de memoria para cada
2918 instrucción antes de pasar a la siguiente, lo que lleva a una definida
2926 (*) es más probable que las cargas deban completarse de inmediato para
2927 permitir progreso en la ejecución, mientras que los stores a menudo se
2933 (*) las cargas se pueden hacer de forma especulativa, lo que lleva a que
2941 cuando se habla con memoria o hardware de E/S, que puede realizar
2947 mecanismos de coherencia pueden aliviar esto, una vez que el store
2948 haya accedido al caché- no hay garantía de que la gestión de la
2951 Entonces, digamos que lo que otra CPU podría observar en el fragmento de
2959 Sin embargo, se garantiza que una CPU es autoconsistente: verá que sus
2970 y asumiendo que no hay intervención de una influencia externa, se puede
2971 suponer que el resultado final se parecerá a:
2978 El código anterior puede hacer que la CPU genere la secuencia completa de
2984 cualquier combinación de elementos combinados o descartados, siempre que la
2986 que READ_ONCE() y WRITE_ONCE() -no- son opcionales en el ejemplo anterior,
2987 ya que hay arquitecturas donde una CPU determinada podría reordenar cargas
2989 WRITE_ONCE() hacen lo que sea necesario para evitar esto, por ejemplo, en
2991 que GCC emita las instrucciones especiales ld.acq y st.rel
2992 (respectivamente) que impiden dicha reordenación.
2995 secuencia antes incluso de que la CPU los vea.
3006 ya que, sin una barrera de escritura o WRITE_ONCE(), puede que se asuma
3007 que el efecto del almacenamiento de V a *A se pierde. Similarmente:
3024 La CPU DEC Alpha es una de las CPU más relajadas que existen. No solo eso,
3025 algunas versiones de la CPU Alpha tienen un caché de datos dividido, lo que
3028 de dirección realmente se vuelve necesaria, ya que se sincronizan ambos
3029 cachés con el sistema de coherencia de memoria, lo que hace que parezca un
3030 cambio en el puntero, frente a que los nuevos datos se produzcan en el
3041 Los "guests" (invitados) que se ejecutan en máquinas virtuales pueden verse
3048 bajo nivel virt_mb() etc. Estas tienen el mismo efecto que smp_mb(), etc.