Eine Frage wie die meine wurde fragte aber meine ist ein bisschen anders. Die Frage lautet: "Warum ist das Schlüsselwort volatile nicht erlaubt in C# bei Typen System.Double y System.Int64 usw.?"
Auf den ersten Blick antwortete ich meinem Kollegen: "Nun, auf einem 32-Bit-Rechner brauchen diese Typen mindestens zwei Ticks, um überhaupt in den Prozessor zu gelangen, und das .Net-Framework hat die Absicht, prozessorspezifische Details wie diese zu abstrahieren." Daraufhin antwortete er: "Es abstrahiert nichts, wenn es Sie daran hindert, eine Funktion aufgrund eines prozessorspezifischen Problems zu nutzen!"
Er meint damit, dass ein prozessorspezifisches Detail einer Person, die ein Framework verwendet, das solche Details vom Programmierer "abstrahiert", nicht auffallen sollte. Das Framework (oder C#) sollte also davon abstrahieren und das tun, was es tun muss, um die gleichen Garantien zu bieten für System.Double usw. (ob das nun eine Semaphore, eine Speicherbarriere oder was auch immer ist). Ich habe argumentiert, dass der Rahmen nicht den Overhead einer Semaphore auf volatile weil der Programmierer bei einem solchen Schlüsselwort nicht mit einem solchen Overhead rechnet, denn eine Semaphore ist für 32-Bit-Typen nicht erforderlich. Der größere Overhead für die 64-Bit-Typen könnte überraschen, so dass es für das .Net-Framework besser ist, es einfach nicht zuzulassen und Sie dazu zu bringen, Ihre eigene Semaphore für größere Typen zu verwenden, wenn der Overhead akzeptabel ist.
Daraufhin haben wir untersucht, was es mit dem flüchtigen Schlüsselwort auf sich hat. (siehe ce Seite). Auf dieser Seite heißt es in den Anmerkungen:
In C# garantiert die Verwendung des Modifikators Volatile für ein Feld, dass jeder Zugriff auf dieses Feld VolatileRead oder VolatileWrite verwendet.
Hmmm..... VolatileRead y VolatileWrite beide unterstützen unsere 64-Bit-Typen!! Meine Frage ist also,
"Warum ist das Schlüsselwort volatile nicht erlaubt in
C#bei TypenSystem.DoubleySystem.Int64usw.?"
