Les lectures de champs volatils ont acquis une sémantique . Cela signifie qu'il est garanti que la mémoire lue à partir de la variable volatile se produira avant toute lecture de mémoire suivante. Il empêche le compilateur d'effectuer la réorganisation, et si le matériel l'exige (CPU faiblement ordonné), il utilisera une instruction spéciale pour que le matériel vide toutes les lectures qui se produisent après la lecture volatile mais qui ont été démarrées de manière spéculative tôt, ou le CPU pourrait empêcher leur émission anticipée en premier lieu, en empêchant toute charge spéculative de se produire entre l'émission de l'acquisition de charge et son retrait.
Les écritures de champs volatiles ont une sémantique de publication . Cela signifie qu'il est garanti que toute écriture mémoire dans la variable volatile sera retardée jusqu'à ce que toutes les écritures mémoire précédentes soient visibles par les autres processeurs.
Prenons l'exemple suivant:
something.foo = new Thing();
Si fooest une variable membre dans une classe et que d'autres processeurs ont accès à l'instance d'objet référencée par something, ils peuvent voir la valeur foochanger avant que les écritures en mémoire dans le Thingconstructeur ne soient globalement visibles! C'est ce que signifie «mémoire faiblement ordonnée». Cela peut se produire même si le compilateur a tous les magasins dans le constructeur avant le magasin foo. Si fooc'est le cas, volatilele magasin fooaura une sémantique de publication, et le matériel garantit que toutes les écritures avant l'écriture sur foosont visibles par les autres processeurs avant d'autoriser l'écriture foo.
Comment est-il possible que les écritures foosoient si mal réorganisées? Si le foostockage de la ligne de cache se trouve dans le cache et que les magasins du constructeur ont manqué le cache, il est alors possible que le magasin se termine beaucoup plus tôt que les écritures dans le cache échouent.
L'architecture Itanium (horrible) d'Intel avait une mémoire faiblement ordonnée. Le processeur utilisé dans la XBox 360 d'origine avait une mémoire faiblement ordonnée. De nombreux processeurs ARM, y compris le très populaire ARMv7-A, ont une mémoire faiblement ordonnée.
Les développeurs ne voient souvent pas ces courses de données parce que des choses comme les verrous feront une barrière de mémoire complète, essentiellement la même chose que d'acquérir et de publier une sémantique en même temps. Aucune charge à l'intérieur de la serrure ne peut être exécutée de manière spéculative avant l'acquisition de la serrure, elles sont retardées jusqu'à ce que la serrure soit acquise. Aucun stockage ne peut être retardé lors d'une libération de verrou, l'instruction qui libère le verrou est retardée jusqu'à ce que toutes les écritures effectuées à l'intérieur du verrou soient globalement visibles.
Un exemple plus complet est le modèle «Verrouillage vérifié». Le but de ce modèle est d'éviter d'avoir à toujours acquérir un verrou pour initialiser paresseusement un objet.
Accroché sur Wikipedia:
public class MySingleton {
private static object myLock = new object();
private static volatile MySingleton mySingleton = null;
private MySingleton() {
}
public static MySingleton GetInstance() {
if (mySingleton == null) { // 1st check
lock (myLock) {
if (mySingleton == null) { // 2nd (double) check
mySingleton = new MySingleton();
// Write-release semantics are implicitly handled by marking
// mySingleton with 'volatile', which inserts the necessary memory
// barriers between the constructor call and the write to mySingleton.
// The barriers created by the lock are not sufficient because
// the object is made visible before the lock is released.
}
}
}
// The barriers created by the lock are not sufficient because not all threads
// will acquire the lock. A fence for read-acquire semantics is needed between
// the test of mySingleton (above) and the use of its contents. This fence
// is automatically inserted because mySingleton is marked as 'volatile'.
return mySingleton;
}
}
Dans cet exemple, les magasins du MySingletonconstructeur peuvent ne pas être visibles par les autres processeurs avant le magasin mySingleton. Si cela se produit, les autres threads qui regardent mySingleton n'acquériront pas de verrou et ils ne récupéreront pas nécessairement les écritures dans le constructeur.
volatilen'empêche jamais la mise en cache. Ce qu'il fait, c'est garantir l'ordre dans lequel les autres processeurs "voient" les écritures. Une libération du magasin retardera un magasin jusqu'à ce que toutes les écritures en attente soient terminées et qu'un cycle de bus ait été émis, indiquant aux autres processeurs de rejeter / réécrire leur ligne de cache s'ils ont les lignes pertinentes mises en cache. Une acquisition de charge videra toutes les lectures spéculées, garantissant qu'elles ne seront pas des valeurs périmées du passé.