Pourquoi ne volatils existent?

volatile est nécessaire si vous lisez à partir d'un endroit en mémoire que, disons, un tout autre processus/périphérique/tout ce que peut écrire à.

J'ai l'habitude de travailler avec dual-port ram dans un système multiprocesseur à droite C. Nous avons utilisé un matériel gérés 16 bits valeur d'un sémaphore de savoir quand l'autre gars a été fait. Essentiellement, nous l'avons fait:

void waitForSemaphore()
{
   volatile uint16_t* semPtr = WELL_KNOWN_SEM_ADDR;/*well known address to my semaphore*/
   while ((*semPtr) != IS_OK_FOR_ME_TO_PROCEED);
}

Sans volatile, l'optimiseur voit dans la boucle inutile (Le gars ne définit jamais la valeur! Il est fou, se débarrasser de ce code!) et mon code, de procéder sans avoir acquis le sémaphore, à l'origine des problèmes plus tard.

Certains processeurs ont registres virgule flottante qui ont plus de 64 bits de précision (par exemple. 32-bit x86 sans l'ESS, voir Pierre du commentaire). De cette façon, si vous exécutez plusieurs opérations sur les nombres double précision, vous obtenez en fait une plus grande précision de réponse que si vous étiez à tronquer chaque résultat intermédiaire à 64 bits.

C'est généralement grand, mais cela signifie que, en fonction de la manière dont le compilateur attribué registres et ne optimisations, vous aurez des résultats différents pour les mêmes opérations sur exactement les mêmes entrées. Si vous avez besoin de cohérence, alors vous pouvez forcer chaque opération pour revenir à la mémoire en utilisant le mot clé volatile.

Il est également utile pour certains algorithmes, qui n'ont pas de sens algébrique, mais de réduire à virgule flottante erreur, comme Kahan sommation. Algebraicly c'est un nop, il sera souvent incorrectement optimisé à moins que certaines variables intermédiaires sont volatiles.

Vous DEVEZ utiliser volatils lors de la mise en œuvre sans verrouillage des structures de données. Sinon le compilateur est libre pour optimiser les accès à la variable, qui va changer la sémantique.

Pour le dire autrement, la volatilité indique au compilateur que l'accès à cette variable doit correspondre à une mémoire physique opération de lecture/écriture.

Par exemple, c'est comment InterlockedIncrement est déclaré dans l'API Win32:

LONG __cdecl InterlockedIncrement(
  __inout  LONG volatile *Addend
);

En C Standard, l'un des lieux de l'utilisation volatile est avec un gestionnaire de signal. En fait, en C Standard, tout ce que vous pouvez faire en toute sécurité dans un gestionnaire de signal est de modifier un volatile sig_atomic_t variable, ou d'en sortir rapidement. En effet, autant que je sache, c'est le seul endroit dans la Norme C que l'utilisation de volatile est nécessaire pour éviter un comportement indéfini.

ISO/IEC 9899:2011 §7.14.1.1 La signal fonction

¶5 Si le signal se produit que sur le résultat de l'appel à la abort ou raise fonction, la
le comportement est indéfini si le gestionnaire de signal se réfère à un objet statique ou thread
durée de stockage qui n'est pas un lock-atomique sans autre objet que par l'attribution d'une valeur à une
objet déclaré que volatile sig_atomic_t, ou le gestionnaire de signal appelle une fonction
de la bibliothèque standard, autres que les abort fonction, le _Exit fonction, la
quick_exit de la fonction, ou la signal fonction avec le premier argument égal à la
numéro de signal correspondant au signal qui a provoqué l'invocation de la gestionnaire.
En outre, si un tel appel à la signal résultats de la fonction dans un SIG_ERR retour, l'
la valeur de errno est indéterminée.²⁵²⁾

²⁵²⁾ Si un signal est généré par un asynchrones gestionnaire de signal, le comportement est indéfini.

Qui signifie que dans le Standard C, vous pouvez écrire:

static volatile sig_atomic_t sig_num = 0;

static void sig_handler(int signum)
{
    signal(signum, sig_handler);
    sig_num = signum;
}

et pas grand chose d'autre.

POSIX est beaucoup plus indulgent sur ce que vous pouvez faire dans un gestionnaire de signal, mais il y a encore des limitations (et l'une des limitations est que le Standard de la bibliothèque d'e/S — printf() et al — ne peut être utilisé en toute sécurité).

Je l'ai utilisé dans les versions de débogage lorsque le compilateur insiste sur l'optimisation de loin une variable que je veux être en mesure de voir que je code pas à pas.

1. vous devez l'utiliser pour mettre en œuvre des spinlocks ainsi que certains (tous?) sans verrouillage des structures de données
2. l'utiliser avec des opérations atomiques/instructions
3. m'a aidé une fois de surmonter la compilation de bug (à tort code généré au cours de l'optimisation)

À côté du fait que le mot clé volatile est utilisé pour dire au compilateur de ne pas optimiser l'accès à une variable (qui peut être modifié que par un fil ou une routine d'interruption), il peut également être utilisé pour enlever les quelques bugs du compilateur -- OUI, il peut être ---.

Par exemple, j'ai travaillé sur une plate-forme intégrée ont été le compilateur a été faire quelques mauvais assuptions concernant la valeur d'une variable. Si le code n'est pas optimisé le programme s'exécuter sur ok. Avec les optimisations (qui étaient vraiment besoin parce que c'était une critique de routine) le code ne fonctionnerait pas correctement. La seule solution (bien que pas très correct), a été de déclarer la 'défectueux' variable volatile.

Dans les premiers jours de C, les compilateurs d'interpréter toutes les actions que lire et écrire des lvalues que les opérations de mémoire, pour être exécutée dans la même séquence que le lit et écrit est apparu dans le code. L'efficacité pourrait être grandement améliorée dans de nombreux cas, si les compilateurs ont donné un certain montant de la liberté de ré-ordonner et de consolider les activités, mais il y a un problème avec cela. Même les opérations ont souvent été spécifié dans un certain ordre simplement parce qu'il était nécessaire de les spécifier dans certains, et donc le programmeur choisi l'une des nombreuses également de bonnes alternatives, que ce n'était pas toujours le cas. Parfois, il serait important que certaines opérations se produire dans un ordre particulier.

Exactement les détails de séquençage sont importants variera en fonction de la plate-forme cible et domaine d'application. Plutôt que de fournir particulièrement détaillées de contrôle, la Norme a opté pour un modèle simple: si une séquence d'accès sont fait avec des lvalues qui ne sont pas qualifiés volatile, un compilateur peut réorganiser et de les consolider, comme il l'entend. Si une action est menée avec une volatilequalifiés lvalue, une qualité de mise en œuvre devrait offrir tout autre des garanties de classement pourrait être requis par le code de ciblage de sa plate-forme et le champ d'application, sans avoir à exiger l'utilisation de la non-standard de la syntaxe.

Malheureusement, plutôt que d'identifier quelles garanties les programmeurs ont besoin, de nombreux compilateurs ont plutôt opté pour offrir le minimum de garanties mandaté par la Norme. Cela rend volatile beaucoup moins utile qu'elle ne devrait l'être. Sur gcc ou clang, par exemple, un programmeur d'avoir à mettre en œuvre une base de "hand-off mutex" [celui où une tâche qui a acquis et a publié un mutex de ne pas le faire à nouveau jusqu'à ce que l'autre a fait] doit faire l'une des quatre choses:

1. Mis l'acquisition et la libération du mutex dans une fonction, le compilateur ne peut pas inline, et à laquelle il ne peut pas s'appliquer pour l'Ensemble du Programme d'Optimisation.

2. Qualifier tous les objets gardé par le mutex comme volatile--quelque chose qui ne devrait pas être nécessaire si tous les accès se produire après l'acquisition du mutex et avant de le relâcher.

3. Utilisez l'optimisation de niveau 0 pour forcer le compilateur à générer du code, comme si tous les objets qui ne sont pas qualifiés register sont volatile.

4. Utiliser gcc-directives particulières.

En revanche, lors de l'utilisation d'une plus grande qualité de compilateur, ce qui est plus approprié pour la programmation de systèmes, tels que la cpi, on aurait une autre option:

1. Assurez-vous qu'un volatilequalifiés écriture est réalisé everyplace une acquisition ou de la libération est nécessaire.

L'acquisition d'une base "hand-off mutex" nécessite un volatile lire (à voir si c'est prêt), et ne doit pas nécessiter un volatile écrire ainsi (de l'autre côté de ne pas essayer d'acquérir de nouveau jusqu'à ce qu'il est remis à l'arrière), mais d'avoir à effectuer un sens volatile écrire, c'est toujours mieux que l'une des options disponibles en vertu de la gcc ou clang.