Synchronisation poussée et mot clé volatile

Ce document abordera des considérations poussées quant à la synchronisation dans un cadre multiprogrammé et quant aux impacts de certaines approches OO. Nous y verrons comment produire du code multiprogrammé plus robuste avec C++, puis la section Lectures complémentaires proposera d'autres pistes, y compris pour d'autres langages de programmation.

Multiprogrammation, concurrence et temporaires

#include "Mutex.h"
#include <string>
class zone_transit {
public:
   using value_type = std::string;
private:
   value_type texte;
   Mutex m;
public:
   value_type extraire() {
      value_type temp;
      Autoverrou av{ m };
      temp.swap(texte);
      return temp;
   }
   void ajouter(const value_type &val) {
      Autoverrou av{ m };
      texte += s;
   }
};

Examinons maintenant deux variantes d'une même situation d'utilisation de zone_transit :

#include "zone_transit.h"
#include <string>
#include <atomic>
#include <algorithm>
#include <fstream>
#include <iostream>
#include <windows.h>
using namespace std;
unsigned long __stdcall lecteur(void *);
unsigned long __stdcall afficheur(void *);
class ObjetPartage {
   atomic<bool> fin_lect;
   zone_transit tampon_;
   string fich;
public:
   ObjetPartage(const string &nom) : fin_lect{}, fich{nom} {
   }
   zone_transit& tampon() noexcept {
      return tampon_;
   }
   void fini() {
      fin_lect = true;
   }
   bool est_fini() const noexcept {
      return fin_lect.load();
   }
   const string& nom_fichier() const {
      return fich;
   }
};
int main() {
   ObjetPartage op("in.txt");
   HANDLE h[] = {
      CreateThread(0, 0, lecteur, &op, 0, 0),
      CreateThread(0, 0, afficheur, &op, 0, 0)
   };
   enum { N = sizeof(h)/sizeof(*h) };
   WaitForMultipleObjects(N, h, TRUE, INFINITE);
   for_each(begin(h), end(h), CloseHandle);
}
unsigned long __stdcall lecteur(void *p) {
   auto &op = *static_cast<ObjetPartage *>(p);
   auto &tampon = op.tampon();
   ifstream ifs{op.nom_fichier()};
   for (string s; getline(ifs, s); ) {
      s += '\n';
      tampon.ajouter(s);
      Sleep(0);
   }
   op.fini();
   return {};
}
unsigned long __stdcall afficheur(void *p) {
   auto &op = *static_cast<ObjetPartage *>(p);
   auto &tampon = op.tampon();
   while (!op.est_fini()) {
      auto s = tampon.extraire();
      if (!s.empty()) cout << s;
      Sleep(0);
   }
   return {};
}

Le code de ExempleOk.cpp est sans danger. Cela dit, examinez le programme suivant :

#include "zone_transit.h"
#include <string>
#include <atomic>
#include <algorithm>
#include <fstream>
#include <iostream>
#include <windows.h>
unsigned long __stdcall lecteur(void *);
unsigned long __stdcall afficheur(void *);
using namespace std;
class ObjetPartage {
   atomic<bool> fin_lect;
   zone_transit tampon_;
   string fich;
public:
   ObjetPartage(const string &nom) : fin_lect{}, fich{nom} {
   }
   zone_transit& tampon() noexcept {
      return tampon_;
   }
   void fini() noexcept {
      fin_lect = true;
   }
   bool est_fini() const {
      return fin_lect.load();
   }
   const string& nom_fichier() const {
      return fich;
   }
};
int main() {
   ObjetPartage op("in.txt");
   HANDLE h[] = {
      CreateThread(0, 0, lecteur, &op, 0, 0),
      CreateThread(0, 0, afficheur, &op, 0, 0)
   };
   enum { N = sizeof(h)/sizeof(*h) };
   WaitForMultipleObjects(N, h, TRUE, INFINITE);
   for_each(begin(h), end(h) CloseHandle);
}
unsigned long __stdcall Lecteur(void *p) {
   auto &op = *static_cast<ObjetPartage *>(p);
   auto &tampon = op.tampon();
   ifstream ifs{op.nom_fichier()};
   for (string s; getline(ifs, s); ) {
      tampon.ajouter(s);
      tampon.ajouter("\n");
      Sleep(0);
   }
   op.fini();
   return {};
}
unsigned long __stdcall afficheur(void *p) {
   auto &op = *static_cast<ObjetPartage *>(p);
   auto &tampon = op.tampon();
   while (!op.est_fini()) {
      auto s = tampon.extraire();
      if (!s.empty()) cout << s;
      Sleep(0);
   }
   return {};
}

Le changement est extrêmement mineur, du moins en apparence. Pourtant, ExempleDanger.cpp plantera fréquemment mais irrégulièrement sur de gros fichiers in.txt. Évidemment, la question est pourquoi?

Une subtilité plutôt... subtile

Il faut comprendre ce que provoque l'exécution de l'opération ajouter("\n"); d'une instance de zone_transit pour comprendre la mécanique qui mène à notre problème de plantage à l'exécution.

Le littéral "\n" est de type const char*. La classe zone_transit n'offre pas de méthode nommée ajouter() prenant en paramètre un const char*, mais propose par contre une méthode ajouter() prenant en paramètre un const std::string&. De plus, le type std::string propose un constructeur prenant en paramètre un const char*. Ne reste plus au moteur d'inférence de types de C++ qu'à faire le raccord et à solliciter automatiquement le constructeur en question pour générer une variable temporaire du type requis (const std::string&) à partir du type d'origine (const char*). C'est, en fait, tellement normal en apparence, tellement inscrit dans nos habitudes qu'on tend à oublier à quel point cette mécanique est... magique.

Mais qui dit magie dit danger. En effet, la création un peu spontanée d'une temporaire entraîne une question importante: quand, exactement, la temporaire sera-t-elle créée? Et jusqu'à quand, exactement, existera-t-elle? Pris de loin, ou pris dans une situation monprogrammée, il n'y a pas de réelle différence entre les deux cas. Cela dit, dans une situation multiprogrammée comme la nôtre, l'une des deux versions a pour impact d'entraîner des effets de bord excessivement pervers.

#include "Mutex.h"
#include <string>
class zone_transit {
public:
   using value_type = std::string;
private:
   value_type texte;
   Mutex m;
public:
   value_type extraire() {
      value_type temp;
      Autoverrou av{ m };
      texte.swap(temp);
      return temp;
   }
   //
   // Version simulant manuellement ce que fait le compilateur
   //
   void ajouter(const char *txt) {
      //
      // création d'une temporaire
      //
      auto s = txt;
      {
         //
         // Bloc anonyme servant à simuler le début de la méthode
         // (normalement, l'accolade de la méthode sert à cette fin).
         // J'insère un bloc ici pour bien montrer la portée de
         // l'Autoverrou av ci-dessous.
         //
         Autoverrou av{ m };
         texte += s;
      } // fin de la portée de l'Autoverrou av
   } // fin de la portée de la chaîne s
};

Quel est le piège?

Pour comprendre le piège, il faut savoir que le type std::string a deux particularités, qu'il partage avec la plupart des types de STL, une partie importante de la bibliothèque standard de C++ :

• Il s'agit d'un type extrêmement optimisé, et
• Il s'agit d'un type qui n'est pas blindé contre les problèmes pouvant résulter de situations de multiprogrammation – ce n'est pas un type Thread-Safe

Prenez quelques instants pour examiner la classe chaine dans le document sur les classes imbriquées à l'adresse http://h-deb.ca/Sujets/Divers--cplusplus/CPP--Classes-imbriquees.html

La classe std::string utilise, pour fins d'optimisation, un schème de représentation interne partageable (le Copy of Write) dans la même lignée que la classe chaine::chaineRep présentée sur cette page. Prenez soin d'assimiler cette information. C'est une bonne technique OO d'optimisation dans un programme monoprogrammé, mais pour un cas multiprogrammé comme celui-ci, elle est extrêmement dangereuse.

En résumé, cette technique va comme suit :

• Copier une std::string ne signifie pas copier son contenu, mais bien faire en sorte que l'original et la copie partagent le même contenu, représenté par une classe interne partageable[1]
• Une copie locale du contenu d'une std::string ne sera faite qu'au moment où on s'apprête à modifier ce contenu, de manière à éviter qu'une instance de std::string ne corrompe accidentellement ses semblables

Revenons au code de ajouter() et de extraire(), ci-dessus, en nous souvenant que la version de ajouter() ici a été modifiée à la main pour simuler le comportement du code généré par le compilateur et dans le but d'éclaircir le propos :

• Le corps de la méthode extraire() prend un mutex via un Autoverrou pour la totalité de son exécution
• Le corps de la méthode ajouter() prend le même mutex via un Autoverrou pour la totalité de son exécution, mais à cause de la génération implicite d'une std::string temporaire à l'intérieur de la méthode, événement qui ne se produira avec la méthode originale que si celle-ci est appelée avec en paramètre un const char* plutôt qu'une std::string déjà formée, il y aura un bref moment où, à la toute fin de l'exécution de cette méthode où :
  • le mutex sera déjà relâché dans ajouter(), l'instance de Autoverrou étant détruit avant la std::string temporaire
  • dans la mesure où texte était vide avant l'appel à ajouter(), la std::string temporaire et l'attribut texte partageront les mêmes données, et
  • parce que nous sommes dans un contexte multiprogrammé, il est possible que extraire() soit appelé pendant ce dangereux instant. Les circonstances, la taille de la chaîne partagée et la fréquence d'itération des divers threads influencera la probabilité que ceci se produise, mais cette probabilité est non-nulle – cela va se produire

La conséquence d'une telle situation est que deux threads se retrouveront à modifier en même temps et à l'insu l'un de l'autre une donnée complexe – un objet contenant une séquence de caractères – et l'un, changeant des attributs comme par exemple la taille de la chaîne ou le pointeur menant vers les données – risque de corrompre l'autre. Le destructeur de la temporaire et les opérations entreprises par extraire() seront nos coupables.

Comment s'en sortir?

unsigned long __stdcall lecteur(void *p) {
   // ...using...
   auto &op= *static_cast<ObjetPartage *>(p);
   auto &tampon = op.tampon();
   ifstream ifs{op.nom_fichier()};
   for (string s; getline(ifs, s)); ) {
      tampon.ajouter(s);
      static const string NOUVELLE_LIGNE = "\n";
      tampon.ajouter(NOUVELLE_LIGNE);
      Sleep(0);
   }
   op.fini();
   return {};
}

class zone_transit {
   // ...
   using value_type = std::string;
   // ...
   void ajouter(value_type s) {
      Autoverrou av{ m };
      texte += s;
      s.clear();
   }
};

class zone_transit {
   // ...
   using value_type = std::string;
   // ...
   void ajouter(const value_type &s) {
      // ...using...
      Autoverrou av{ m };
      copy(begin(s), end(s), back_inserter(texte));
   }
};

Laisser le compilateur nous assister – objets qualifiés volatile

int compter_secondes(atomic<bool> &fin) {
   int ntours = 0;
   while (!fin) {
      ++ntours;
      Sleep(1000); // approx. une seconde (pas archi précis)
   }
   return ntours;
}

Mais si cette variable est utilisée dans un programme multiprogrammé, comme celui ci-dessous, cette optimisation (qu'on souhaiterait, dans la plupart des cas) peut transformer le sens du programme et nuire à son bon fonctionnement!

#include <iostream>
#include <atomic>
#include <windows.h>
// ... using ... compter_secondes(), omis pour sauver de l'espace ...
unsigned long __stdcall compter(void *p) {
   auto &fin = *static_cast<atomic<bool>*> (p);
   int nsec = compter_secondes(fin);
   cout << "Temps écoulé: " << nsec << " secondes" << endl;
   return {};
}
int main() {
   atomic<bool> fin { false };
   HANDLE h = CreateThread(0, 0, compter, &fin, 0, 0);
   Sleep(10000); // ou lire une touche, ou...
   // la variable fin est modifiée dans main() mais consultée dans
   // compter_secondes(), qui est appelée par le thread compter()
   fin = true;
   WaitForSingleObject(h, INFINITE);
   CloseHandle(h);
}

La multiprogrammation entraîne son lot de contraintes, mais on ne saurait s'en passer dans le monde de l'informatique contemporaine. En même temps, il ne faudrait pas omettre des techniques d'optimisation avantageuses dans le monde de la monoprogrammation (et utiles dans la plupart des cas même en situation de multiprogrammation!) pour éviter des erreurs qui ne surviendront que sur certaines variables bien précises.

Il serait à peine plus complexe – et combien plus efficace! – de demander aux programmeurs de modules multiprogrammés d'identifier clairement, dans leurs programmes, les variables pour lesquelles il est essentiel que le compilateur ne procède à aucune optimisation porteuse de risque; les variables si volatiles qu'on doit présumer que leur état peut changer sans avertissement à cause de l'action de forces extérieures[3].

Les langages de programmation qui proposent un support à la multiprogrammation, à plus forte partie les langages dérivés syntaxiquement du langage C, comme le sont C++, Java et C#, permettent d'identifier ces variables par un mot clé.

Utiliser des données spécifiées volatile

Nous allons explorer l'utilisation de ce mot, d'abord par un exemple simple (celui proposé plus haut, qui pourrait aisément s'écrire en C, en Java ou en C#), puis avec des techniques OO plus complexes mais aussi plus riches.

C++ sera notre langage pour explorer plus à fond le concept de volatile et ses applications, puisque c'est le seul langage d'entre ceux mentionnés plus haut qui offre un support complet pour l'encapsulation – ce qui, nous le verrons rapidement, sera une nécessité pour bien présenter certaines de nos approches.

Cas banal – empêcher des optimisations trop agressives

#include <windows.h>
#include <iostream>
int compter_secondes(volatile bool &fin) {
   int nb_tours = 0;
   while (!fin) {
      ++nb_tours;
      Sleep(1000); // une seconde
   }
   return nb_tours;
}
unsigned long __stdcall Compter(void *p) {
   using namespace std;
   bool &fin = *static_cast<bool*>(p);
   int nb_sec = compter_secondes(fin);
   cout << "Temps écoulé: " << nb_sec << " secondes" << endl;
   return {};
}
int main() {
   volatile bool fin = false;
   HANDLE hTh = CreateThread(0, 0, Compter, const_cast<bool*>(&fin), 0, 0);
   Sleep(10000); // ...
   fin = true;
   WaitForSingleObject(hTh, INFINITE);
   CloseHandle(hTh);
}

class Synchro {
  volatile int cpt;
public:
   Synchro() noexcept : cpt{} {
   }
   void attendre() const noexcept {
      for (int avant = cpt; avant == cpt; Sleep(10))
         ;
   }
   void evenement() noexcept
      { ++cpt; }
};
unsigned long __stdcall mise_veille(void *p) {
   auto &sync = *static_cast<Synchro *>(p);
   sync.attendre();
   return {};
}
#include <iostream>
unsigned long __stdcall lire_touche(void *p) {
   using std::cin;
   auto &sync = *static_cast<Synchro *>(p);
   char c;
   cin >> c;
   sync.evenement();
   return {};
}
#include <windows.h>
#include <algorithm>
int main() {
   using namespace std;
   Synchro sync;
   HANDLE h[] = {
      CreateThread(0,0,mise_veille, &sync,0,0),
      CreateThread(0,0,lire_touche, &sync,0,0)
   };
   enum { N = sizeof(h) / sizeof(*h) };
   WaitForMultipleObjects(N, h, TRUE, INFINITE);
   for_each(begin(h), end(h), CloseHandle);
}

Parenthèse – retour sur const et const_cast

struct X {
   void f();
   void g() const;
};
void f0(int *);
void f1(int &);
void f2(int);
void g0(const int*);
void g1(const int&);
int main() {
   const int VAL = 3;
   int *p = &VAL; // ILLÉGAL
   int &r = VAL;  // ILLÉGAL
   int i = VAL;   // LÉGAL
   f0(&VAL);      // ILLÉGAL
   f1(VAL);       // ILLÉGAL
   f2(VAL);       // LÉGAL
   VAL = 4;       // ILLÉGAL
   g0(&VAL);      // LÉGAL
   g1(VAL);       // LÉGAL
   const X x;
   x.f();         // ILLÉGAL
   x.g();         // LÉGAL

// ...
   // présomption: f1() est
   // inoffensive pour son
   // paramètre, malgré son
   // prototype peu rigoureux
   f1(const_cast<int&>(VAL));
}

La maxime selon laquelle si on peut qualifier quelque chose de const, alors on devrait sans doute le faire est souvent, très souvent, des plus valables. Reste qu'il faut être pragmatique et faire avec les cas où il y a eu négligence.

int temp = VAL;
f(temp);

f(const_cast<int>(VAL));

#include <string>
#include <iostream>
//
// f() est bénigne pour s, mais on a
// négligé de spécifier s « const »
//
void f(std::string &s) {
   std::cout << s;
}
int main() {
   using std::string;
   const string BIENVENUE = "Coucou!";
   f(BIENVENUE); // ILLÉGAL
   //
   // On ne veut pas créer une copie de
   // BIEVENUE, car on veut profiter du gain
   // de vitesse dû au fait qu'on évite une
   // copie de par le passage par référence
   //
   f(const_cast<string&>(BIENVENUE));
}

Relation entre const, mutable et volatile

Il existe une relation particulière entre ces mots clés que sont const, mutable et volatile. En effet :

• On qualifie par const une donnée qui ne change pas dans la portée où on l'utilise, ce qui permet au compilateur de nous protéger contre des erreurs de programmation et lui permet de procéder à des optimisations qui ne sont possibles que si l'état de la donnée reste inchangé
• On qualifie aussi par const une méthode qui garantit que les états de l'instance à laquelle elle appartient resteront inchangés suite à son exécution. Seules les méthodes const peuvent être invoquées sur une instance qualifiée const, par définition
• On peut trouver, dans un même objet, deux méthodes qui ne diffèrent en signature que par la présence ou non de la spécification const. La version const devrait être privilégiée si possible, et on aura recours version qui n'est pas const dans les cas seuls où elle est nécessaire
• On qualifie de mutable un attribut qui doit être soustrait aux règles imposées par la spécification const appliquée à une instance. Le mot mutable n'est pas véritablement l'inverse du mot const, même si on le laisse parfois entendre par abus de langage, mais s'apparente plus à une espèce de clause dérogatoire à laquelle on peut avoir recours pour certaines opérations pragmatiques. Contrairement au mot const, le mot mutable ne s'applique pas aux méthodes

L'exemple ci-dessous montre des exemples de méthodes déclinées en versions const et non const, de même qu'un exemple d'attribut mutable (donc sujet à changer de valeur même dans une situation où l'instance qui en est propriétaire devrait demeurer inchangée) :

class Chaine {
public:
   using size_type = int;
   using value_type = char;
private:
   const size_type taille_;
   value_type *texte;
   // compte les appels à taille(), pour fins statistiques
   mutable int cpt_appels;
public:
   // Exceptions possibles
   class TailleIllegale {};
   class HorsBornes {};
   Chaine(size_type lg) : texte{}, taille_(lg), cpt_appels{} {
      if (taille() <= 0) throw TailleIllegale();
      texte = new char[taille()];
   }
   // combinaison de méthode const et d'attribut mutable
   size_type taille() const noexcept {
      ++ cpt_appels;
      return taille_;
   }
   // versions const et non const d'une même opération
   value_type operator[](size_type i) const {
      if (i < 0 || i >= taille()) throw HorsBornes{};
      return texte[i];
   }
   value_type& operator[](size_type i) {
      if (i < 0 || i >= taille()) throw HorsBornes{};
      return texte[i];
   }
   //
   // ajouter la Sainte-Trinité
   //
};

Sachant cela, examinons de plus près comment exploiter la spécification volatile :

• On qualifie de volatile une donnée ou un objet dont l'état est susceptible de changer en tout temps et pour des raisons qui ne sont pas nécessairement apparentes au compilateur dans l'exercice de ses fonctions, et
• On qualifie de volatile une méthode d'instance pouvant être utilisée à partir d'un pointeur ou d'une référence sur un objet lui-même volatile.

Il faut donc comprendre méthode volatile au sens de méthode pouvant être appelée d'une instance elle-même qualifiée volatile. Une méthode volatile est une méthode que le programmeur estime sécuritaire à solliciter chez une instance qualifiée volatile.

Relation entre volatile et const – un comparatif

Pour aider à situer la relation entre les mots volatile et const, voici quelques petits tableaux comparatifs[6]. En espérant que le tout vous soit utile.

Mot clé volatile et limites du compilateur

Un compilateur de qualité peut (doit!) offrir un support très strict du mot clé const et du concept qui y est associé. La possibilité de qualifier const des méthodes permet d'ailleurs à un compilateur de valider le respect des règles associées à ce concept et de s'assurer à la compilation qu'aucune de ces règles n'est violée dans un programme donné.

Le compilateur peut offrir un certain secours aux développeurs de systèmes multiprogrammés en reconnaissant la spécification volatile sur des objets et en bloquant à la compilation l'invocation de méthodes de cet objet qui ne seraient pas elles-mêmes garanties volatile. Toutefois, ce qui permet à un programmeur de qualifier volatile ou non une méthode est plus flou que ce qui lui permet de qualifier une méthode const.

Certaines règles sont faciles à reconnaître et à mettre en place :

• Sur une instance qualifiée volatile, n'accepter d'invoquer que les méthodes elles-mêmes qualifiées volatile
• Dans une méthode qualifiée volatile d'une instance X, rejeter les tentatives d'invocation de méthodes d'attributs de X qui ne seraient pas elles-mêmes qualifiées volatile, et
• dans une méthode qualifiée volatile d'une instance X, rejeter les tentatives d'invocation de méthodes de X qui ne seraient pas elles-mêmes qualifiées volatile

C'est quand même peu (bien que semblable) en comparaison avec le vaste support accordé aux objets et aux méthodes const. C'est pourtant la limite du support raisonnable: la multiprogrammation est une chose complexe et qui dépend de plusieurs facteurs, ce qui la rend plus difficile à analyser et à valider de manière unitaire – la constance d'un objet sur la base de certaines opérations est chose plus simple à valider localement dans la mesure où les opérations sont récursivement porteuses de leurs propres garanties de constance.

Comment un compilateur pourrait-il savoir qu'une méthode qualifiée volatile (donc sécuritaire pour invocation sur un objet volatile) l'est vraiment? Serait-il suffisant de vérifier qu'elle exploite un outil de synchronisation comme un mutex ou un sémaphore (ou une qualification synchronized telle qu'on les rencontre en Java)? Faudrait-il vérifier que ces outils sont-ils bien utilisés? Comment pourrait-on réaliser une telle analyse sans connaissance du contexte dans lequel la méthode sera invoquée?

Dans l'état courant du savoir à ce sujet, ce problème est insoluble.

Le mot clé volatile en action

#include "Mutex.h"
#include <string>
class zone_transit { // SANS PROTECTION
public:
   using value_type = std::string;
private:
   Mutex m;
   value_type texte;
public:
   void ajouter(const value_type &s) {
     texte += s;
  }
   value_type extraire() {
      auto s = texte;
      texte.clear();
      return s;
   }
   bool empty() const noexcept {
      return texte.empty();
   }
};

// ...
int main() {
   zone_transit ts;
   volatile zone_transit vts;
   ts.ajouter("ts");
   vts.ajouter("vts");
}

La version de la classe zone_transit proposée à ci-dessous est préférable aux versions précédentes en ce sens qu'elle offre des versions sécurisées (volatile) et non sécurisées de chaque méthode pertinente. Le compilateur choisira la version de chaque méthode en fonction de la qualification volatile ou non de l'instance propriétaire de la méthode.

#include "Mutex.h"
#include <string>
class zone_transit {
public:
   using value_type = std::string;
private:
   Mutex m;
   value_type texte;
public:
   void ajouter(const value_type &s) {
      texte += s;
   }
   void ajouter(const value_type &s) volatile {
      Autoverrou av(const_cast<Mutex&>(m));
      const_cast<value_type &>(texte) += s;
   }
   value_type extraire() {
      auto s = texte;
      texte.clear();
      return s;
   }
   value_type extraire() volatile {
      Autoverrou av(const_cast<Mutex&>(m));
      auto s = const_cast<value_type &>(texte);
      const_cast<value_type &>(texte).clear();
      return s;
   }
   bool empty() const noexcept {
      return texte.empty();
   }
   bool empty() const volatile noexcept {
      Autoverrou av(const_cast<Mutex&>(m));
      return const_cast<value_type &>(texte).empty();
   }
};

Ou encore, pour une écriture plus élégante, la version suivante, qui fait des méthodes qualifiées volatile un simple enrobage injectant des primitives de synchronisation autour des méthodes brutes (ce qui réduit la complexité de l'entretien du code).

#include "Mutex.h"
#include <string>
class zone_transit {
public:
   using value_type = std::string;
private:
   Mutex m;
   value_type texte;
public:
   void ajouter(const value_type &s) {
      texte += s;
   }
   void ajouter(const value_type &s) volatile {
      Autoverrou av(const_cast<Mutex&>(m));
      const_cast<zone_transit *>(this)->ajouter(s);
   }
   value_type extraire() {
      auto s = texte;
      texte.clear();
      return s;
   }
   value_type extraire() volatile {
      Autoverrou av(const_cast<Mutex&>(m));
      return const_cast<zone_transit *>(this)->extraire();
   }
   bool empty() const noexcept {
      return texte.empty();
   }
   bool empty() const volatile noexcept {
      Autoverrou av(const_cast<Mutex&>(m));
      return const_cast<zone_transit *>(this)->empty();
   }
};

Vous remarquerez sans doute la présence de quelques conversions explicites de types ISO (des const_cast) dans le code en exemple. Examinons-les de plus près.

Méthodes spécifiées volatile et objets Thread Oblivious

Les types STL (comme std::string, std::vector, std::stack et ainsi de suite) qui peuplent les bibliothèques standard de C++. ne sont généralement pas des types Thread-Safe, en ne sont donc pas des types protégés contre les accès concurrents.

Une méthode spécifiée volatile ne peut pas utiliser directement des attributs qui ne sont pas volatile. Cela tombe sous le sens, un peu comme le fait qu'une méthode spécifiée const d'un objet constitué en partie d'autre objets, par composition ou par agrégation, ne peut utiliser de ces objets que des méthodes elles-mêmes qualifiées const.

En effet, si une méthode garantit la constance de l'instance qui en est propriétaire pour la durée de son exécution, elle ne peut faire appel aux méthodes de ses attributs qui offrent elles aussi de telles garanties. De manière symétrique, un objet offrant une méthode volatile (donc sécurisée) ne peut avoir recours, à l'intérieur de cette méthode, qu'aux méthodes de ses attributs qui sont elles aussi volatile, donc Thread-Safe.

Tout comme on peut enlever temporairement la spécification const sur un objet, on peut aussi enlever temporairement la spécification volatile. Dans chaque cas, la conversion à appliquer est un const_cast.

Dans notre exemple plus haut, l'instance de std::string nommée texte et servant d'attribut à une instance de zone_transit pose problème si le zone_transit en question est volatile, du fait que les attributs d'un objet volatile sont eux aussi qualifiés volatile. Sachant que std::string n'expose aucune méthode volatile, cet attribut serait inutilisable dans une méthode volatile de l'instance à laquelle il appartient.

Il importe donc de pouvoir supprimer temporairement la qualification volatile de texte quand on désire s'en servir dans une méthode volatile – évidemment, il faut alors que la méthode ait pris les dispositions pour protéger texte puisque, par définition, texte ne se protège pas lui-même.

Les const_cast<std::string&> y sont donc nécessaires pour utiliser une std::string dans une méthode volatile de zone_transit; on présume évidemment que chaque méthode exploitant ce mécanisme a pris au préalable des dispositions pour assurer la sécurité de la std::string en situation multiprogrammée.

Une méthode extraire() en temps constant (complexité $O(1)$)

Les exemples ci-dessus montrent une méthode extraire() implémentée comme suit :

#include "Mutex.h"
#include <string>
class zone_transit {
public:
   using value_type = std::string;
private:
   Mutex m;
   value_type texte;
public:
   // ...
   value_type extraire() {
      auto s = texte;
      texte.clear();
      return s;
   }
   // ...
};

Cette méthode a un gros défaut, soit celui de générer une (pour ne pas dire deux) copie(s) du contenu complet de texte. Par conséquent, cette méthode est de complexité linéaire ($O(n)$, où $n$ est texte.size()). Une alternative en temps constant ($O(1)$) irait comme suit :

#include "Mutex.h"
#include <string>
class zone_transit {
public:
   using value_type = std::string;
private:
   Mutex m;
   value_type texte;
public:
   // ...
   value_type extraire() {
      value_type s;
      s.swap(texte);
      return s;
   }
   // ...
};

Voyez la nuance (qui se base sur des techniques analogues à celles sous-jacentes à l'implémentation usuelle de l'idiome d'affectation sécuritaire) :

• Le constructeur par défaut du conteneur, string::string(), s'exécute en temps constant
• La méthode swap() permute essentiellement des pointeurs et des entiers, et
• Le retour par mouvement (ici, std::move(s) est probablement superflu, la plupart des compilateurs étant capables de constater qu'à ce stade, s est jetable) se fait en temps constant

Notez qu'il est tentant d'écrire ce qui suit :

#include "Mutex.h"
#include <string>
class zone_transit {
public:
   using value_type = std::string;
private:
   Mutex m;
   value_type texte;
public:
   // ...
   value_type extraire() {
      return std::move(texte);
   }
   // ...
};

... mais ce serait pour le moins risqué : la norme nous indique que les constructeurs de mouvement doivent faire en sorte que l'objet duquel sont déplacés les états (ici : texte) soit destructible après le mouvement, sans plus. Nous ne pouvons donc présumer par exemple que texte représente une chaîne vide suite à std::move(texte), même s'il serait plausible que l'implémentation mène à cette conclusion.

Lectures complémentaires

Quelques liens pour enrichir le propos.

• Pour un autre article sur le même sujet, envisagez lire ceci : http://www.ddj.com/dept/cpp/184403766, écrit par Andrei Alexandrescu, qui montre en quoi volatile, appliqué à un objet, peut vous être d'une grande utilité
• Le mot volatile a son utilité, mais celle-ci n'est peut-être pas ce que vous aviez en tête : http://cxx.isvolatileusefulwiththreads.com/
• En 2007, Arch D. Robison rappelle que volatile est utile, mais probablement pas pour la synchronisation entre threads : https://software.intel.com/en-us/blogs/2007/11/30/volatile-almost-useless-for-multi-threaded-programming/
• À propos de la capacité qu'ont les compilateurs et les processeurs de jouer avec l'ordre des opérations en mémoire dans les microprocesseurs contemporains : http://www.linuxjournal.com/article/8211
• Texte de Herb Sutter en 2007 distinguant ce à quoi sert volatile de ce à quoi il ne devrait pas servir, du moins en C++ : http://www.drdobbs.com/parallel/volatile-vs-volatile/212701484
• Comment bien utiliser le mot clé volatile en langage C  : http://www.netrino.com/Embedded-Systems/How-To/C-Volatile-Keyword
• L'aide sur MSDN peut aussi être utile, mais notez que certains éléments de ce lien sont spécifiques au compilateur de Microsoft et donnent à ce mot un sens divergeant quelque peu de celui proposé par le standard : http://msdn2.microsoft.com/en-us/library/12a04hfd(VS.80).aspx

Cependant, volatile n'est pas une panacée, et quand on le prend pour autre chose que ce que c'est, on peut prendre ce mot en grippe. Pour quelques critiques de volatile en C++, voir :

• Le mot volatile appliqué à une variable est souvent inadéquat. Pour une exploration des risques de cette pratique dans la programmation du noyau de Linux, voir https://www.kernel.org/doc/Documentation/volatile-considered-harmful.txt
• Une critique d'un développeur chez Intel : http://software.intel.com/en-us/blogs/2007/11/30/volatile-almost-useless-for-multi-threaded-programming/
• Une discussion : http://groups.google.com/group/comp.programming.threads/browse_frm/thread/1fa4a82dda916b18/fd6be8f0b18bd62d?#fd6be8f0b18bd62d
• Neuf manières de briser votre programme C avec ce mot clé : http://blog.regehr.org/archives/28
• Article de 2008 mettant de l'avant que plusieurs compilateurs compilent le mot clé volatile incorrectement, par Eric Eide et John Regehr : http://www.cs.utah.edu/~regehr/papers/emsoft08-preprint.pdf
• Texte de John Regehr, en 2010, portant sur le fait que bien des compilateurs C ou C++ implémentent incorrectement le support à la qualification volatile : http://blog.regehr.org/archives/41
• Le mot clé volatile devrait-il impliquer l'atomicité? Pas clair que ce soit le cas : http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2016.html
• Recommandations de la GSL à propos du mot clé volatile (ces recommandations ne discutent pas des méthodes qualifiées volatile) :
  • ne pas confondre variable volatile et variable atomique : https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rconc-volatile
  • utiliser volatile pour accéder à de la mémoire « non-C++ » : https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rconc-volatile2
• Texte de 2022 par Arthur O'Dwyer qui donne une explication raisonnablement accessible de ce que signifie volatile lorsque ce mot est apposé à une variable d'un type primitif : https://quuxplusone.github.io/blog/2022/01/28/volatile-means-it-really-happens/

Le mot clé volatile existe aussi dans d'autres langages, et son sens varie d'un langage à l'autre :

• En C# :
  • Jon Skeet à propos des variables volatile en C# : http://jonskeet.uk/csharp/threads/volatility.html
  • https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/volatile et https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/language-specification/classes#volatile-fields pour la documentation officielle du langage
  • En 2017, Joydip Kanjilal explique quand il est sage d'utiliser volatile en C# : https://www.infoworld.com/article/3229360/how-to-use-the-volatile-keyword-in-c.html
  • http://www.codeproject.com/KB/threads/volatile_look_inside.aspx
  • https://www.dotnetperls.com/volatile
  • La vision de Yan Cui, en 2010 : https://theburningmonk.com/2010/03/threading-understanding-the-volatile-modifier-in-csharp/
• En Java :
  • http://www.javaperformancetuning.com/tips/volatile.shtml
  • http://www.javalobby.org/forums/thread.jspa?threadID=17270
  • le sens à donner au mot volatile en Java, selon Jeremy Manson en 2008 (merci à Myriam Luce pour le lien!) : http://jeremymanson.blogspot.ca/2008/11/what-volatile-means-in-java.html
  • explications d'Eugen Paraschiv : http://www.baeldung.com/java-volatile

Comparaison du code généré pour des calculs sur un entier, un entier volatile et un entier atomique, par Marc Brooker en 2013 : http://brooker.co.za/blog/2013/01/06/volatile.html

En 2016, Hugo V. Texteira montre à quel point le traitement de volatile est inégal d'un compilateur à l'autre : https://componenthouse.com/2016/10/21/a-note-about-the-volatile-keyword-in-cpp/

Dans le mouvement de dépréciation de volatile, l'équipe de Qt a investi des efforts importants dans la réduction du recours à ce mot clé. Texte de 2020 par Giuseppe D'Angelo : https://www.kdab.com/getting-rid-of-volatile-in-some-of-qt/

En 2021, Niall Cooling discute des effets de la dépréciation de volatile sur le développement de systèmes embarqués : https://blog.feabhas.com/2021/05/modern-embedded-c-deprecation-of-volatile/