Discussion :

[cob59]

Bonjour � tous

Je viens de tomber sur cet article de A.Alexandrescu datant de f�vrier 2001, et j'en viens � m'interroger sur cette approche qui consiste � qualifier en volatile non pas les types primitifs, mais les objets thread-safe eux-m�me et leurs m�thodes.

J'aimerais avoir votre avis l� dessus.

Est-ce toujours d'actualit� ?
Vis � vis de Boost.Thread, cette approche est-elle compl�mentaire, superflue, proscrite, ... ?

[screetch]

volatile n'est pas suffisant et est souvent faux, pour faire du vrai thread safe il faut utiliser des memory barriers et des op�rations thread-safe comme des operations interlocked et des mutex (qui ont le bon gout d'�tre aussi des memory barriers)

une memory barrier et/ou une instruction interlocked instruit au compilateur que la memoire peut avoir chang� et donc va desactiver certaines optimisations autour de cette instruction - mais pas partout comme le volatile le fait.

le volatile est pr�vu pour quelque chose d'autre, a ne pas utiliser.

[Ekleog]

[...]
le volatile est pr�vu pour quelque chose d'autre, a ne pas utiliser.

Et qu'est-ce que ce "quelque chose d'autre" ?

Au passage, si le mutex est g�r� dans une librairie annexe, comment le compilateur peut-il savoir qu'il ne faut pas optimiser autour de cet appel � une librairie externe ?

[screetch]

justement parce que tu ne sais pas quel etat peut etre modifi� par une biblitheque annexe. quand tu appeles printf, tes variables globales sont recharg�es car le compilateur ne sait pas ce qui peut avoir chang� a l'interieur de printf.
et volatile etait utilis� pour les variables qui pouvaient changer de valeur sans intervention du programme; une valeur mapp�e en m�moire que le hardware pouvait mettre a jour.

[Ekleog]

Mais si ce n'est pas une variable globale, mais que les deux threads poss�dent tous deux un pointeur vers un objet d�clar� sur le tas, est-ce que cette variable sera �galement recharg�e � la suite d'un appel � une librairie externe ?
Et si c'est un pointeur vers un objet d�clar� sur le tas ?
Si les r�ponses sont oui, alors tout appel � une librairie externe oblige � recharger toute la m�moire. Ce qui est quand m�me peu performant.
Si les r�ponses sont non, alors volatile a encore une utilit� en dehors de la modification par le hardware.

[cob59]

J'ai l'impression que vous n'avez pas lu l'article jusqu'au bout.
A.A. ne propose pas de s�curiser des donn�es avec volatile. Il utilise d�j� des mutex et des �quivalents de boost::scoped_lock dans ses exemples pour pr�venir les acc�s concurrents � ses donn�es. Ce qui m'interroge, c'est cette mani�re qu'il a d'utiliser le qualifier volatile qui me semble presque d�tourn�e :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
/* Let's illustrate how volatile works on user-defined types on an example. */
 
class Gadget
{
public:
    void Foo() volatile;
    void Bar();
    ...
private:
    String name_;
    int state_;
};
...
Gadget regularGadget;
volatile Gadget volatileGadget;
 
/* If you think volatile is not that useful with objects, prepare for some surprise. */
 
volatileGadget.Foo(); // ok, volatile fun called for volatile object
 
 
regularGadget.Foo();  // ok, volatile fun called for non-volatile object
volatileGadget.Bar(); // error! Non-volatile function called for volatile object!

D'ailleurs, � propos de l'utilisation "classique" de volatile, il pr�cise m�me :

Don't use volatile directly with primitive types.

[screetch]

l'utilit� de volatile n'est pas de corriger les probl�mes de threads, vraiment. j'ai fait une biblioth�que de multithread avec un peu de mutex, beaucoup d'interlocked et pas de volatile, et je n'ai pas eu de probl�me.
mais les variables partag�es doivent utiliser des *vrais* moyens, portables, de partage entre threads (ce que volatile n'est pas, ou est seulement indirectement)