Y a-t-il un avantage d'utiliser des mots-clés volatils contrairement à utiliser la classe verrouillée?

Oui, vous pouvez regarder la valeur directement.

Tant que vous n'utilisez la classe verrouillée que pour accéder à la variable, alors il n'y a pas de différence. Ce que volatiles em> est-il indique au compilateur que la variable est spéciale et si elle optimise ne devrait pas supposer que la valeur n'a pas changé. P>

prend cette boucle: p >

bool done = false;

...

while(!done)
{
... do stuff which the compiler can prove doesn't touch done...
}

éditer: Question largement réécrit em>

Pour répondre à cette question, j'ai divisé un peu plus loin dans la matière et j'ai découvert quelques choses sur volatile code> et Imbriqué code> que je n'étais pas au courant. Clarifions cela, non seulement pour moi, mais pour cette discussion et d'autres personnes qui lisent sur ceci: p>

• volatile code> lecture / écriture est censé être à l'abri de la réorganisation. Ceci seulement em> signifie la lecture et l'écriture, il est pas em> nuire à toute autre action; li>
• volatilité em> n'est pas forcé sur la CPU, c'est-à-dire que le niveau de matériel (X86 utilise des clôtures d'acquisition et de libération sur tout em> lecture / écriture). Il empêche les optimisations du compilateur ou du CLR; Li>
• interclocké code> utilise des instructions d'assemblage atomique pour comparaisonxchange ( cmPxchg code>), incrément ( inc code>) etc; li>
• interclocké code> utilise-t-il parfois un verrou ": a verrouillage du matériel sur les systèmes multi-processeurs ; Dans les systèmes UNI-processeur, il n'y a pas de verrouillage matériel; li>
• interclocké code> est différent de volatile code> en ce qu'elle utilise une clôture totale em>, où volatile utilise une demi-clôture. LI>
• Une lecture après une écriture peut être réorganisée lorsque vous utilisez volatile code>. Cela ne peut pas arriver avec interclocké code>. volatileread code> et volatilwrite code> avoir le même problème de réorganisation comme `volatile (lien grâce à Brian Gideon). Li> ul>

  Maintenant que nous avons les règles, nous pouvons définir une réponse à votre question: p>

  • Techniquement: Oui, il y a des choses que vous pouvez faire avec volatile code> que vous ne pouvez pas faire avec interclocké code>:
    1. Syntaxe: Vous ne pouvez pas écrire a = b code> où a code> ou b code> est volatile, mais c'est évident; li>
    2. Vous pouvez lire une valeur différente après l'avoir écrite à une variable volatile en raison de la réorganisation. Vous ne pouvez pas faire cela avec interclocké code>. En d'autres termes: vous pouvez être moins em> sûr avec volatile code>, alors vous pouvez être avec interclocké code>. Li>
    3. Performances: volatile code> est plus rapide que interclocké code>. li> ol> li>

    4. sémantiquement: non, car interclocké code> fournit simplement une superset d'opérations et est plus sûr d'utiliser car elle applique une clôture complète. Vous ne pouvez rien faire avec volatile code> que vous ne pouvez pas faire avec interclocké code> et que vous pouvez faire beaucoup em> avec interclocké code> que vous ne pouvez pas faire avec volatile: p>

       static volatile int x = 0;
       x++;                        // non-atomic
       static int y = 0;
       Interlocked.Increment(y);   // atomic
       

    5. Scope: Oui, déclarant une variable volatile code> le rend volatil pour chaque accès. Il est impossible de forcer ce comportement n'importe quel autre moyen, donc volatile code> ne peut pas être remplacé par en verrouillé code>. Ceci est nécessaire dans des scénarios où d'autres bibliothèques, interfaces ou matériels peuvent accéder à votre variable et la mettre à jour à tout moment ou besoin de la version la plus récente. P> Li> ul>

       Si vous me demandiez, ce dernier bit est le besoin réel réel de volatile code> et peut le rendre idéal où deux processus partagent la mémoire et doivent lire ou écrire sans verrouillage. Déclarant une variable comme volatile code> est beaucoup plus sûre dans ce contexte, puis forçant tous les programmeurs à utiliser interclocké code> (que vous ne pouvez pas forcer par le compilateur). P>

       ---

       Edit: La citation suivante faisait partie de ma réponse originale, je le laisserai dans; -) em> p>

       une citation du langage de programmation C # em> standard: p>

       pour les champs non volatils, optimisation techniques qui considèrent que la réorganisation Les instructions peuvent conduire à inattendus et des résultats imprévisibles dans programmes multithreads qui accèdent champs sans synchronisation tels que qui fournit par la Lock-énoncé em>. Ces optimisations risquent d'être effectuées par le compilateur, par le système d'exécution, ou par matériel. Pour les champs volatils, Ces optimisations de réorganisation sont restreint: p>

       • une lecture d'un champ volatil est appelé un lecture volatile em> strong>. Une lecture volatile a: acquérir une sémantique »; c'est-à-dire qu'il est garanti de se produire avant tout Références à la mémoire qui se produisent après dans la séquence d'instructions. P> li>

       • Une écriture d'un champ volatil est appelé un écrit volatile em> fort>. UNE L'écriture volatile a "libération sémantique "; c'est-à-dire qu'il est garanti arriver après toutes les références de mémoire avant l'instruction d'écriture dans le Séquence d'instruction. P> LI> ul> blockQuote>

         mise à jour: em> strong> question est en grande partie réécrit, corrigé ma réponse originale et ajouté une "vraie" réponse p> p> p> P>