Discussion :

[screetch]

Jamais il ne dit qu'il ne faudrait pas utiliser volatile. Il dit simplement que volatile est moins utile pour les types intégrés que pour les types déclarés par l'utilisateur.

Non, c'est vrai, jamais il dit ca, c'est moi qui dit ca

http://software.intel.com/en-us/blog...d-programming/
Sauf qu'ils ne parlent pas de la même chose. Ici, Arch Robison parle de volatile pour des types intégrés au langage (zut, j'ai oublié le nom ... les int & co. , quoi)
Alors que de l'autre côté, c'est des structures que alexandrescu parle. Au passage, il dit même que le volatile sur les int&co est beaucoup moins utile, et que celui-ci est déconseillé par lui.

http://stackoverflow.com/questions/4...ulti-threading
Déjà, je remarque que la réponse la plus up-votée renvoie vers un lien vers l'article d'alexandrescu. Hasard ou non ?
Et pour les reste des réponses, elles ne parlent que des int&co.

http://drdobbs.com/parallel/212701484
Même remarque : Ici, on parle encore des int&co.

attention il y a quand même un peu de confusion sur l'article;
il y a deux aspects, le premier: un booleen volatile résout le problème de la boucle while, c'est la partie que je déclare fausse.

la second partie, est un moyen différent d'obtenir le même résultat.

en gros:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
struct Blabla
{
  void run()
  {
    while(!m_done)
    {...
    }
  }
  bool m_done;
};

il dit en gros que ce code ne fonctionne pas avec des optimisations.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
struct Blabla
{
  void run()
  {
    while(!m_done)
    {...
    }
  }
  volatile bool m_done;
};

ce code fonctionne mais on ne devrait pas le faire comme ca.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
struct Blabla
{
  void run() volatile
  {
    while(!m_done)
    {...
    }
  }
  bool m_done;
};

d'après lui ce code fonctionne et est beau, car il utilise le compilateur pour forcer un check du "volatile". Or, si je ne critique pas le principe d'utiliser volatile comme on utilise const, je critique encore une fois le fait qu'il dise que ce code fonctionne.
Pour info il fonctionnerait si un objet était marqué volatile; alors on pourrait utiliser run() dessus ainsi:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
static volatile Blabla s_sharedBlabla;
s_sharedBlabla.run();

Pourquoi ca "marche" d'après lui? parce que le fait d'avoir collé volatile sur l'instance va faire que tous les champs deviennent volatile (come quand un objet est const, tous ses champs deviennent const par la même occasion)
du coup le booléen devient volatile, du coup la fonction remarche.

Il s'agit donc de coller du volatile sur chacun des membres dans une méthode volatile comme ca n est sur que le thread safe marchera.

OR, si j'aime l'idée d'avoir un check au runtime similaire au const mais pour du thread safe, son idée de base du tout début était fausse; volatile n'est PAS le mot clé a utiliser pour ca.

Voila la partie fausse:

1) Outside a critical section, any thread might interrupt any other at any time; there is no control, so consequently variables accessible from multiple threads are volatile. This is in keeping with the original intent of volatile — that of preventing the compiler from unwittingly caching values used by multiple threads at once.
2) Inside a critical section defined by a mutex, only one thread has access. Consequently, inside a critical section, the executing code has single-threaded semantics. The controlled variable is not volatile anymore — you can remove the volatile qualifier.

c'est faux, faux, faux, en tous cas le 1), il n'y a que le 2) qui est vrai. en dehors du mutex, comme tes instances sont volatiles, il utilise l'effet de volatile qui n'est pas le bon pour s'assurer que les optimisations sont desactivées. C'est porki est incorrect.
Cependant je ne nie pas le 2) ca serait bien pratique. Si volatile n'avait pas ces effets indésirés.