Sind MSIL Opcodes atomar?

8

Ich habe ein bisschen mit dem MSIL-Decompiler - ILDASM gespielt und versucht, eine einfache .NET-Methode zu dekompilieren.

Die Opcodes sahen irgendwie so aus:

%Vor%

Was ich mich wundere ist - sind diese Opcodes atomar? Ist es in einem präemptiven Zeitplanungs-Kernel möglich, dass ein einzelner Opcode vor der Ausführung beendet wird? Der Opcode hier könnte leicht zu asm Anweisungen 1: 1 gemappt werden, da sie separate Opcodes für Lasten, Speichern, Addieren usw. haben.

Aber was im Falle eines komplexeren Opcodes? wie "call", wenn der Operand ein Methodenreferenz-Token ist, dem zuerst gefolgt werden sollte, um die Methode aufzulösen und dann aufzurufen? ist das auch Atom?

    
Karim Agha 31.01.2012, 19:56
quelle

2 Antworten

12

Nein, nicht alle Opcodes sind atomar. Wenn Sie beispielsweise stloc oder ldloc für Werttypen verwenden, die größer als die native Zeigergröße sind, ist das nicht garantiert atomar.

In Abschnitt 12.6.6 von ECMA 335 ist dies garantiert:

  

Ein konformes CLI muss garantieren, dass Lese- und Schreibzugriff auf korrekt ausgerichtete Speicherplätze, die nicht größer als die native Wortgröße (die Größe des Typs native int) sind, atomar ist (siehe §12.6.2), wenn alle Schreibzugriffe auf einen Speicherort erfolgen sind gleich groß. Atomare Schreibvorgänge dürfen keine anderen Bits als die geschriebenen ändern.

... aber dann gibt es eine Notiz:

  

[Hinweis: Es gibt keinen garantierten atomaren Zugriff auf 8-Byte-Daten, wenn die Größe eines systemeigenen Int 32 Bit beträgt, obwohl einige Implementierungen atomare Operationen ausführen, wenn die Daten an einer 8-Byte-Grenze ausgerichtet sind. Endnote]

Das bedeutet, dass jeder Op-Code, der Int64 speichert oder liest, nicht garantiert ist, dass er auf x86 atomar ist, zum Beispiel ...

    
Jon Skeet 31.01.2012, 19:58
quelle
0

Ich glaube nicht, dass die Atomarität in IL-Anweisungen definiert ist. Es wird in Bezug auf Lasten definiert und vom / zum Speicher gespeichert.

Und die Regeln für die Atomarität in Bezug auf Lasten und Speicher sind komplex. Sie haben mit Ausrichtung und Größe des gespeicherten Wertes zu tun.

Ihr Beispiel von "call" macht keinen Sinn: Es greift nicht auf den Speicher zu. Das Konzept der Atomizität steht in keinem Zusammenhang mit der Aufrufanweisung.

    
usr 31.01.2012 20:00
quelle

Tags und Links