Ces barrières mémoire, en général appelées d'une primitive assembleur inline, sont également très utilisées en programmation bas niveau.
Classiquement, quand on initialise un contrôleur matériel quelconque on a une tétrachiée de registres de configuration à initialiser avant de mettre un bit d'activation dans un registre de contrôle.
Et si l'ordre précis d'écriture de la tétra-chiée de configs contrôleur off n'importe généralement pas, tout ceci doit être fait avant que le bit d'activation qui va les faire prendre en compte par le matériel ne soit écrit.
C'est par exemple le rôle de la bien nommée instruction "eieio" sur PowerPC par exemple: https://en.wikipedia.org/wiki/Enforce_In-order_Execution_of_I/O
Il y avait d'autres primitives de synchronisation sur cette architecture, mais c'était la moins coûteuse en perf... car elle n'obligeait même pas à faire de suite les accès antérieurs. Juste que quand ce serait le cas, les accès qui suivraient le eieio seraient faite après ceux qui le précédaient.
Si on voulait pouvoir utiliser le matériel juste après (certitude que l'activation soit passée!), mieux valait avoir mis un "mbar 0" ou "msync" (selon les versions de PPC, c'est des alias) juste derrière l'écriture du bit d'activation :o)
Et au delà du load/store, on avait des primitives de synchro côté fetch aussi.
# Fondamental aussi en logiciel de base...
Posté par lym . En réponse au journal Barrières mémoire et buffers circulaires - Un résultat inattendu. Évalué à 2.
Ces barrières mémoire, en général appelées d'une primitive assembleur inline, sont également très utilisées en programmation bas niveau.
Classiquement, quand on initialise un contrôleur matériel quelconque on a une tétrachiée de registres de configuration à initialiser avant de mettre un bit d'activation dans un registre de contrôle.
Et si l'ordre précis d'écriture de la tétra-chiée de configs contrôleur off n'importe généralement pas, tout ceci doit être fait avant que le bit d'activation qui va les faire prendre en compte par le matériel ne soit écrit.
C'est par exemple le rôle de la bien nommée instruction "eieio" sur PowerPC par exemple:
https://en.wikipedia.org/wiki/Enforce_In-order_Execution_of_I/O
Il y avait d'autres primitives de synchronisation sur cette architecture, mais c'était la moins coûteuse en perf... car elle n'obligeait même pas à faire de suite les accès antérieurs. Juste que quand ce serait le cas, les accès qui suivraient le eieio seraient faite après ceux qui le précédaient.
Si on voulait pouvoir utiliser le matériel juste après (certitude que l'activation soit passée!), mieux valait avoir mis un "mbar 0" ou "msync" (selon les versions de PPC, c'est des alias) juste derrière l'écriture du bit d'activation :o)
Et au delà du load/store, on avait des primitives de synchro côté fetch aussi.