voilà une très courte partie d'une classe de téléchargement (quelle surprise, au vu de son nom ) qui doit pouvoir être contrôlée depuis un thread extérieur (ou directement depuis un autre processus, en fait, mais là n'est pas vraiment la question)
J'ai mis en place un système de mutex pour éviter les problèmes d'accès concurrentiels, et ... je me suis dit que préciser que les données de cette classe seraient volatiles aurait pu être un plus :
 

 
Et là, une fois là, je me demande bien ce que je peux faire de ces données, vu que quelle que soit la fonction que je veux utiliser sur les éléments de cette classe, je me fais jeter violemment parce qu'ils sont volatiles. Evidemment, il n'y a pas de "volatile_cast" pour laisser des passages un peu crades comme on pourrait le faire avec un const (très utile au passage quand on utilise une lib C ) donc dois-je me résoudre à retirer ces volatiles ?

c'est de la daube volatile, ça synchronise rien, ça force juste à relire en mémoire (au lieu d'un registre) la données. D'ailleurs ça n'a aucun sens sur les données qui font plus d'un mot. volatile n'a rien à voir avec la synchronisation. oublie ça.

ok, merci

donc tu vas faire quoi ...
 

Non, en fait, à terme, le projet devra plus faire de la communication inter-processus, donc je vais le tester directement avec un système de dialogue qui évitera ce genre d'ennui. Je ne suis pas encore décidé : sockets ? Messages systèmes ? (je pencherais plutôt pour la première solution )
 
et sinon, je ne suis pas sur qu'on accepterait d'utiliser boost dans ma boîte Pour un autre projet, ils ont préféré refaire les fonctionnalités voulues plutôt que l'utiliser

...
 
socket / xmlrpc / etc

 
ça a peut être un petit rapport quand même. J'avais vu dans la glibc, des types atomiques (peut etre dans boost.thread aussi). J'ai pas regardé le code, mais ils doivent etre qualifiés volatile, et exploiter des fonctions bas niveau de l'OS ?  C'est à coup sur plus performant qu'un mutex, mais bon j'ai jamais essayé, et j'ai peut etre pas envi de prendre le risque

volatile est utilisé pour forcer la relecture mémoire. Les types atomic sont implémentés avec des trucs en assembleurs puisque les architectures proposent des solutions pour comparer/swapper/incrémenter des variables : des fois directement, des fois juste pour un seul mot, donc ça conduit à une implémentation avec un mutex. mais volatile ça synchro rien. c'est comme tu dis pour exploiter des trucs bas niveaux genre lecture de registre de périph etc

OK. Et dans la pratique, un utilisateur peut-il avoir une raison légitime de manipuler directement un sig_atomic_t ?

volatile, c'est juste pour dire à l'optimiseur de ne pas faire son boulot sur la variable. Ça m'a sauvé la vie dans un programme une fois déjà. J'en suis encore tout ému car c'était mon premier bug en release qui n'existait pas en debug

je sais pas ce que c'est que sig_atomic_t. Utilise le framework de synchro générique qu'on te fournit : mutex pthread, mutex glib, mutex boost, etc ... mais va pas te faire chier avec les trucs bas niveaux, c'est pas fait pour ça. Pour ma part, je n'ai jamais écrit de code avec volatile.

ben j'en ai pas vraiment l'intention, mais je vois que sig_volatile_t est fourni par la glib
http://theory.uwinnipeg.ca/gnu/glibc/libc_365.html
Je m'interrogeais sur l'utilité qu'on pouvait en avoir ...

attend, je parle de la glib, pas gnu libc

ouais et t'en fais quoi ? pas grand chose, je doute que tu puisse
 
if (lock++) { acquisition } atomiquement sans asm ... poubelle

milles excuses, fourni par la glibc. effectivement, le tintouin de synchronisation est dans des bibliotheques de plus "haut niveau".
Bon on va en restez aux mutex boost ... Pour volatile, le jour ou j'en pose un, je l'encadre (autrement qu'en phase de debogage). C'est à se demander à quoi sert le v dans la branlette intelectuelle sur la cv-qualification.

honnetement je vois mal à quoi pourrait te servir un volatile ...

 
le sig_atomic_t joue peut-etre le role de la ressource à partager, non ?

 
Si, j'ai vu un gus dans ma boite, qui avait fait dans le temps une optimisation chiadée en coupant des pointeurs en deux, ou un truc affreux dans le genre ... Et un jour, il a appris à se servir des optimisations de compil. en -O2, sa boue se vautrait. Alors il a qualifié avec volatile et tout est apparemment entré dans l'odre. Bonjour l'optimisation

 
ben oui.
 
Dans mon forum en C, j'ai des objets partagés, typiquement les topics. J'ai une variable atomic_t pour le nombre de lectures faites sur ce topic parce que ce serait complètement idiot que d'aller utiliser un mutex sur les topics pour gérer l'intégrité d'un pauvre entier. Je m'en sers aussi pour faire du ref count sur mes objets partagés (idem: ce serait idiot que d'utiliser un truc aussi lourd qu'un mutex pour gérer ça).