Freigeben über

Eingeschränkte Ausführungsbereiche

Eine eingeschränkte Ausführungsregion (CER) ist Teil eines Mechanismus zum Erstellen von zuverlässigem verwaltetem Code. Eine CER definiert einen Bereich, in dem die Common Language Runtime (CLR) daran gehindert wird, Out-of-Band-Ausnahmen auszulösen, die verhindern würden, dass der Code im Bereich vollständig ausgeführt wird. Innerhalb dieses Bereichs ist der Benutzercode auf das Ausführen von Code beschränkt, der dazu führen würde, dass Out-of-Band-Ausnahmen ausgelöst werden. Die PrepareConstrainedRegions Methode muss unmittelbar einem try Block vorausgehen und die catch, finally, und fault Blöcke als eingeschränkte Ausführungsbereiche kennzeichnen. Wenn Code als eingeschränkter Bereich markiert ist, muss er nur anderen Code mit starken Zuverlässigkeitsvereinbarungen aufrufen. Code sollte keine unvorbereiteten oder nicht zuverlässigen Methoden zuordnen oder virtuelle Aufrufe für diese vornehmen, es sei denn, der Code ist für die Behandlung von Fehlern ausgelegt. Die CLR verzögert Threadabbrüche für Code, der in einer CER ausgeführt wird.

Von Bedeutung

CER wird nur in .NET Framework unterstützt. Dieser Artikel gilt nicht für .NET Core oder .NET 5 und höher.

Eingeschränkte Ausführungsbereiche werden in der CLR auf verschiedene Weise eingesetzt, zusätzlich zu einem kommentierten try Block, insbesondere durch kritische Finalizer, die in Klassen ausgeführt werden, die von der CriticalFinalizerObject Klasse abgeleitet sind, und durch Code, der mit der ExecuteCodeWithGuaranteedCleanup Methode ausgeführt wird.

CER-Vorbereitung

Die CLR bereitet CERs im Voraus vor, um Speichermangelbedingungen zu vermeiden. Dies ist erforderlich, um zu verhindern, dass die Common Language Runtime bei der JIT-Kompilierung oder beim Laden der Typen einen Arbeitsspeichermangel verursacht.

Der Entwickler muss angeben, dass es sich bei einer Coderegion um eine CER handelt:

Zwänge

Benutzer sind in der Art des Codes eingeschränkt, den sie in einer CER schreiben können. Der Code kann keine Out-of-Band-Ausnahme verursachen, z. B. aus den folgenden Vorgängen:

  • Explizite Zuordnung.

  • Boxen.

  • Erhalten einer Sperre.

  • Virtuelles Aufrufen unvorbereiteter Methoden.

  • Aufrufen von Methoden mit einer schwachen oder nicht vorhandenen Zuverlässigkeitsvereinbarung.

In .NET Framework, Version 2.0, sind diese Einschränkungen Richtlinien. Diagnosen werden über Codeanalysetools bereitgestellt.

Zuverlässigkeitsverträge

Dies ReliabilityContractAttribute ist ein benutzerdefiniertes Attribut, das die Zuverlässigkeitsgarantien und den Korruptionszustand einer bestimmten Methode dokumentiert.

Zuverlässigkeitsgarantien

Zuverlässigkeitsgarantien, dargestellt durch Cer Enumerationswerte, geben den Grad der Zuverlässigkeit einer bestimmten Methode an:

  • MayFail. Unter außergewöhnlichen Bedingungen kann die Methode fehlschlagen. In diesem Fall meldet die Methode zurück an die aufrufende Methode, ob sie erfolgreich war oder fehlgeschlagen ist. Die Methode muss in einer CER enthalten sein, um sicherzustellen, dass sie den Rückgabewert melden kann.

  • None. Die Methode, der Typ oder die Assembly steht nicht mit einem CER in Zusammenhang und kann höchstwahrscheinlich ohne wirksame Schutzmaßnahmen vor Zustandsbeschädigungen nicht sicher aus einem CER aufgerufen werden. Sie nutzt keine CER-Garantien. Dies impliziert Folgendes:

    1. Unter außergewöhnlichen Bedingungen kann die Methode fehlschlagen.

    2. Die Methoden kann Fehler melden oder nicht melden.

    3. Die Methode wird nicht für die Verwendung eines CER geschrieben, das wahrscheinlichste Szenario.

    4. Wenn eine Methode, ein Typ oder eine Assembly nicht explizit identifiziert wird, um erfolgreich zu sein, wird sie implizit als Noneidentifiziert.

  • Success. Unter außergewöhnlichen Bedingungen ist die Methode garantiert erfolgreich. Um dieses Maß an Zuverlässigkeit zu erreichen, sollten Sie immer eine CER um die aufgerufene Methode erstellen, auch wenn sie aus einer Nicht-CER-Region aufgerufen wird. Eine Methode ist erfolgreich, wenn sie erreicht, was beabsichtigt ist, obwohl Erfolg subjektiv betrachtet werden kann. Ein Beispiel: Count wird mit ReliabilityContractAttribute(Cer.Success) markiert. Dies impliziert, dass bei der Ausführung unter einem CER immer ein Wert für die Anzahl von Elementen in der ArrayList zurückgegeben wird und die internen Felder niemals in einem unbestimmten Zustand verbleiben. Die Methode ist jedoch auch als Erfolg gekennzeichnet, mit dem Verständnis, dass der Erfolg bedeuten kann, CompareExchange dass der Wert aufgrund einer Rennbedingung nicht durch einen neuen Wert ersetzt werden konnte. Der wichtigste Punkt ist, dass sich die Methode so verhält, wie sie dokumentiert ist, und CER-Code muss nicht geschrieben werden, um ein ungewöhnliches Verhalten zu erwarten, das über den korrekten, aber unzuverlässigen Code hinausgeht.

Korruptionsstufen

Korruptionsstufen, dargestellt durch Consistency Enumerationswerte, geben an, wie stark der Zustand in einer bestimmten Umgebung korrumpiert werden könnte:

  • MayCorruptAppDomain. Unter außergewöhnlichen Bedingungen garantiert die Common Language Runtime (CLR) nicht die Konsistenz des Zustands in der aktuellen Anwendungsdomäne.

  • MayCorruptInstance. Die Methode beschränkt die Zustandsbeschädigung unter Ausnahmebedingungen garantiert auf die aktuelle Instanz.

  • MayCorruptProcess, unter außergewöhnlichen Bedingungen bietet die CLR keine Garantien in Bezug auf die Zustandskonsistenz; d. h., der Zustand könnte den Prozess verfälschen.

  • WillNotCorruptState. Unter Ausnahmebedingungen beschädigt die Methode den Zustand garantiert nicht.

Zuverlässigkeit von try/catch/finally-Blöcken

Der zuverlässige try/catch/finally-Block ist ein Mechanismus für die Ausnahmebehandlung, dessen Vorhersagbarkeitsgarantie der nicht verwalteten Version entspricht. Der catch/finally Block ist das CER. Methoden im Block erfordern eine gründliche Vorbereitung und müssen nicht unterbrechbar sein.

In .NET Framework Version 2.0 informiert der Code die Laufzeit, dass ein Versuch zuverlässig ist, indem PrepareConstrainedRegions unmittelbar vor einem Try-Block aufgerufen wird. PrepareConstrainedRegions ist ein Mitglied der RuntimeHelpersCompilerunterstützungsklasse. Rufen Sie PrepareConstrainedRegions direkt auf, sofern dies vom Compiler unterstützt wird.

Nicht interruptierbare Regionen

Eine nicht unterbrechungsfreie Region gruppiert eine Reihe von Anweisungen in einer CER.

In .NET Framework, Version 2.0, werden, sofern der Compiler dies unterstützt, im Benutzercode nicht unterbrechbare Bereiche mit einem zuverlässigen try/catch/finally-Block erstellt, der einen leeren try/catch-Block enthält, dem ein PrepareConstrainedRegions-Methodenaufruf vorausgeht.

Kritisches Finalizer-Objekt

Ein CriticalFinalizerObject garantiert, dass die Garbage Collection den Finalizer ausführt. Der Finalizer und sein Aufrufdiagramm werden nach der Zuordnung vorab vorbereitet. Die Finalizer-Methode wird in einer CER ausgeführt und muss allen Einschränkungen für CERs und Finalizer gehorchen.

Für alle Typen, die von SafeHandle und CriticalHandle erben, ist garantiert, dass ihre Finalizer in einem CER ausgeführt werden. Implementieren Sie ReleaseHandle in von SafeHandle abgeleiteten Klassen, um Code auszuführen, der das Handle freigeben soll.

In CERs unzulässiger Code

Die folgenden Vorgänge sind in CERs nicht zulässig:

  • Explizite Zuordnungen.

  • Erhalten einer Sperre.

  • Boxen.

  • Mehrdimensionaler Arrayzugriff.

  • Methodenaufrufe durch Reflektion.

  • Enter oder Lock.

  • Sicherheitsüberprüfungen. Führen Sie keine Anforderungen aus, nur Verknüpfungsanforderungen.

  • Isinst und Castclass für COM-Objekte und Proxys

  • Abrufen oder Festlegen von Feldern für einen transparenten Proxy.

  • Serialisierung.

  • Funktionszeiger und Delegaten.

Siehe auch

  • Last updated on