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)