Pourquoi pas volatile sur System.Double et System.Long?

Question

Une question comme la mienne a été demandé, mais le mien est un peu différent. La question est: "Pourquoi le mot clé volatile n'est autorisé en C# types System.Double et System.Int64, etc....?"

À première vue, j'ai répondu à mon collègue, "eh Bien, sur une machine 32 bits, ces types de prendre au moins deux des tiques à même de saisir le processeur, et la .Net framework qui a l'intention d'abstraction spécifique de processeur détails comme ça." À laquelle il répond, "Ce n'est pas l'abstraction de quelque chose si c'est vous empêchant d'utiliser une fonction à cause d'un processeur spécifique de problème!"

Il implique qu'un processeur spécifique de détail ne devrait pas présenter à une personne à l'aide d'un cadre de "résumés" détails comme ça, loin de le programmeur. Ainsi, le cadre (ou C#) devrait abstraction de ceux-ci et de faire ce qu'il doit faire pour offrir les mêmes garanties pour System.Double, etc. (si c'est un Sémaphore, barrière de mémoire, ou quoi que ce soit). J'ai fait valoir que le cadre ne doit pas ajouter la surcharge d'un Sémaphore sur volatile, parce que le programmeur n'est pas attendu à une telle surcharge avec un tel mot-clé, en raison d'un Sémaphore n'est pas nécessaire pour la version 32 bits de types. La plus grande charge pour la version 64 bits de types peut venir comme une surprise, donc, c'est mieux pour la .Net framework pour juste ne le permet pas, et vous faire votre propre Sémaphore sur les grands types de si la surcharge est acceptable.

À l'origine de notre enquête sur ce que le mot clé volatile est tout au sujet. (voir cette page). Que les états de la page, dans les notes:

En C#, à l'aide de la volatilité modificateur sur un champ garantit que tous les accès à ce champ utilise VolatileRead ou VolatileWrite.

Hmmm.....VolatileRead et VolatileWrite de soutenir notre 64-bit types!! Ma question est donc,

"Pourquoi est-ce le mot clé volatile n'est autorisé en C# types System.Double et System.Int64, etc....?"

Answer 1

Il implique qu'un processeur spécifique de détail ne devrait pas présenter à une personne à l'aide d'un cadre de "résumés" détails comme ça, loin de le programmeur.

Si vous êtes à l'aide de basse-verrouillage des techniques comme les champs volatiles, explicite les barrières de la mémoire, et autres, alors vous êtes totalement dans le monde du processeur des informations spécifiques. Vous avez besoin de comprendre à un niveau profond précisément ce que le processeur est et n'est pas autorisé à faire de réorganisation, de la cohérence, et ainsi de suite, afin d'écrire correct, portable, robuste programmes qui utilisent la basse-lock techniques.

Le but de cette fonctionnalité est de dire "je suis l'abandon de la pratique des abstractions garantis par un seul thread de programmation et d'embrasser les gains de performance possible en ayant une profonde mise en œuvre spécifique de la connaissance de mon processeur." Vous devez vous attendre à moins d'abstractions à votre disposition lorsque vous démarrez à l'aide de basse-lock techniques, pas plus que des abstractions.

Vous allez "down to the metal" pour une raison, sans doute; le prix à payer est d'avoir à traiter avec les caprices de dit en métal.

Answer 2

Oui. La raison est que vous pouvez même pas lire double ou long en une seule opération. Je suis d'accord que c'est une mauvaise abstraction. J'ai le sentiment que la raison en était que la lecture de leur atomiquement exige des efforts et il serait trop intelligent pour le compilateur. Afin qu'ils vous permettent de choisir la meilleure solution: locking, Interlocked, etc.

Chose intéressante, c'est qu'ils peuvent en fait être lu de manière atomique sur 32 bits à l'aide de registres MMX. C'est ce compilateur java JIT n'. Et ils peuvent être lus automatiquement sur un ordinateur 64 bits. Donc je pense que c'est grave défaut de conception.

Answer 3

Pas vraiment une réponse à votre question, mais...

Je suis assez sûr que la documentation MSDN vous faites référence est incorrecte lorsqu'il affirme que "l'utilisation de la volatilité modificateur sur un champ garantit que tous les accès à ce champ utilise VolatileRead ou VolatileWrite".

Directement en lecture ou en écriture à un volatile champ génère uniquement un demi-barrière (une acquisition-clôture lors de la lecture et de la libération de clôture lors de l'écriture).

L' VolatileRead et VolatileWrite méthodes MemoryBarrier en interne, ce qui génère un plein de clôture.

Joe Duffy connaît une chose ou deux au sujet de la programmation simultanée; c'est ce qu'il a à dire à propos de volatile:

(En aparté, de nombreuses personnes s'étonnent de la différence entre les charges et les magasins de variables marquées comme étant volatile et des appels à enfiler.VolatileRead et Fil de discussion.VolatileWrite. La différence c'est que les premiers sont des Api mise en œuvre plus fort que le jitted code: ils permettent d'atteindre acquisition/diffusion la sémantique en émettant complète de clôtures sur le côté droit. Les Api sont plus cher appeler trop, mais au moins vous permettent de décider sur un callsite par callsite base qui les charges individuelles et les magasins ont besoin de l' MM garantie.)

Answer 4

C'est une explication simple de l'héritage. Si vous lisez cet article - http://msdn.microsoft.com/en-au/magazine/cc163715.aspxvous verrez que la seule mise en œuvre de l' .NET Framework 1.x runtime était sur des machines x86, donc il est logique pour Microsoft de mettre en œuvre contre le x86 modèle de mémoire. x64 et IA64 ont été ajoutés plus tard. De sorte que la base du modèle de mémoire a toujours été l'un des x86.

Aurait-il été mis en œuvre pour x86? Je ne suis vraiment pas sûr qu'il peut être complètement mis en œuvre - une ref d'un double retourné à partir de code natif pourraient être alignées sur 4 octets au lieu de 8. Dans ce cas, tous vos garanties atomiques, des lectures/écritures ne sont plus valables.