Partager via

Régions d’exécution contraintes

Une région d’exécution contrainte (CER) fait partie d’un mécanisme permettant de créer du code managé fiable. Un cer définit une zone dans laquelle le Common Language Runtime (CLR) est contraint de lever des exceptions hors bande qui empêcheraient l’exécution du code dans la zone dans son intégralité. Dans cette région, le code utilisateur ne peut pas exécuter de code qui entraînerait la levée d’exceptions hors-bande. La PrepareConstrainedRegions méthode doit immédiatement précéder un try bloc et marquer catch, finallyet fault les blocs comme régions d’exécution contraintes. Une fois marqué comme une région contrainte, le code ne doit appeler que d’autres codes avec des contrats de fiabilité forts, et le code ne doit pas allouer ou effectuer des appels virtuels à des méthodes non préparées ou non fiables, sauf si le code est prêt à gérer les défaillances. Le CLR retarde les abandons de thread pour le code qui s’exécute dans une région CER.

Importante

CER est uniquement pris en charge dans .NET Framework. Cet article ne s’applique pas à .NET Core ou .NET 5 et versions ultérieures.

Les régions d’exécution contraintes sont utilisées sous différentes formes dans le CLR en plus d’un bloc annoté try , notamment des finaliseurs critiques qui s’exécutent dans des classes dérivées de la CriticalFinalizerObject classe et du code exécutés à l’aide de la ExecuteCodeWithGuaranteedCleanup méthode.

Préparation préalable au CER

Le CLR prépare les régions CER à l’avance pour éviter toute condition de mémoire insuffisante. Une préparation est nécessaire pour que le CLR ne provoque pas d’insuffisance de mémoire pendant le chargement de type ou la compilation juste-à-temps.

Le développeur doit indiquer qu’une région de code est une cer :

Contraintes

Les utilisateurs sont contraints dans le type de code qu’ils peuvent écrire dans un cer. Le code ne peut pas provoquer d’exception hors bande, comme cela peut résulter des opérations suivantes :

  • Allocation explicite

  • Boxe.

  • Acquisition d’un verrou.

  • Appel de méthodes non préparées de manière virtuelle

  • Appel de méthodes avec un contrat de fiabilité faible ou inexistant

Dans .NET Framework version 2.0, ces contraintes sont des instructions. Les diagnostics sont fournis par le biais d’outils d’analyse du code.

Contrats de fiabilité

Il ReliabilityContractAttribute s’agit d’un attribut personnalisé qui documente les garanties de fiabilité et l’état d’altération d’une méthode donnée.

Garanties de fiabilité

Les garanties de fiabilité, représentées par Cer des valeurs d’énumération, indiquent le degré de fiabilité d’une méthode donnée :

  • MayFail Dans des conditions exceptionnelles, la méthode peut échouer. Dans ce cas, elle indique à la méthode appelante si elle a réussi ou échoué. La méthode doit être incluse dans un CER afin de garantir qu'elle puisse signaler la valeur de retour.

  • None La méthode, le type et l’assembly n’ont aucun concept de région CER. Il est probablement risqué de les appeler dans une région CER sans atténuation substantielle contre les risques d’altération de l’état. Elle ne profite pas des garanties CER. Cela implique les éléments suivants :

    1. Dans des conditions exceptionnelles, la méthode peut échouer.

    2. La méthode peut ou non signaler qu’elle a échoué.

    3. La méthode n'est pas conçue pour utiliser un CER, ce qui est le scénario le plus probable.

    4. Si une méthode, un type ou un assembly n’est pas identifié explicitement pour réussir, il est implicitement identifié comme None.

  • Success Dans des conditions exceptionnelles, la méthode est garantie de réussir. Pour atteindre ce niveau de fiabilité, vous devez toujours construire un CER autour de la méthode appelée, même lorsqu'elle est appelée à partir d'une région non-CER. Une méthode réussit si elle accomplit ce qui est prévu, bien que la réussite puisse être vue subjectivement. Par exemple, le fait de marquer Count avec ReliabilityContractAttribute(Cer.Success) implique qu’en cas d’exécution dans une région CER, elle retourne toujours le nombre d’éléments dans le ArrayList et ne peut jamais laisser les champs internes dans un état indéterminé. Toutefois, la méthode CompareExchange est aussi marquée comme ayant réussi, étant entendu que la réussite peut signifier que la valeur n’a pas pu être remplacée par une nouvelle valeur à cause d’une condition de concurrence. Le point clé est que la méthode se comporte de la façon dont elle est documentée pour se comporter, et le code CER n’a pas besoin d’être écrit pour s’attendre à un comportement inhabituel au-delà de ce que le code correct mais non fiable ressemblerait.

Niveaux de corruption

Les niveaux de corruption, représentés par Consistency : des valeurs d’énumération, indiquent dans quelle mesure l'état peut être corrompu dans un environnement donné.

  • MayCorruptAppDomain Dans des conditions exceptionnelles, le Common Language Runtime (CLR) ne garantit pas la cohérence de l’état dans le domaine d’application actuel.

  • MayCorruptInstance Dans des conditions exceptionnelles, il est garanti que la méthode limite l’altération de l’état à l’instance actuelle.

  • MayCorruptProcess, dans des conditions exceptionnelles, le CLR ne garantit pas la cohérence de l’état ; autrement dit, la condition peut endommager le processus.

  • WillNotCorruptState Dans des conditions exceptionnelles, la méthode est garantie de ne pas endommager l’état.

Bloc try/catch/finally de fiabilité

La fiabilité try/catch/finally est un mécanisme de gestion des exceptions avec le même niveau de garantie de prévisibilité que la version non managée. Le bloc catch/finally est la région CER. Les méthodes du bloc nécessitent une préparation anticipée et doivent être noninterruptibles.

Dans .NET Framework version 2.0, le code informe le runtime qu’une tentative est fiable en appelant PrepareConstrainedRegions immédiatement avant un bloc try. PrepareConstrainedRegions est membre de RuntimeHelpers, une classe de support de compilateur. Appelez PrepareConstrainedRegions directement en attente de sa disponibilité via les compilateurs.

Régions noninterruptibles

Une région non interruptible regroupe un ensemble d’instructions dans un CER.

Dans le .NET Framework version 2.0, dans l’attente de la disponibilité par le biais de la prise en charge du compilateur, le code utilisateur crée des régions non interruptibles avec un bloc try/catch/finally fiable qui contient un bloc try/catch vide précédé d’un appel de méthode PrepareConstrainedRegions.

Objet finaliseur critique

Un CriticalFinalizerObject garantit que le garbage collection exécutera le finaliseur. Lors de l’allocation, le finaliseur et son graphique des appels sont préparés à l’avance. La méthode finaliseur s’exécute dans un CER et doit respecter toutes les contraintes sur les CER et les finaliseurs.

Tous les types qui héritent de SafeHandle et CriticalHandle ont la garantie que leur finaliseur s'exécute dans un environnement d'exécution CER. Implémentez ReleaseHandle dans SafeHandle les classes dérivées pour exécuter tout code requis pour libérer le handle.

Code non autorisé dans les CER

Les opérations suivantes ne sont pas autorisées dans les CER :

  • Allocations explicites

  • Acquisition d’un verrou.

  • Boxe.

  • Accès au tableau multidimensionnel.

  • Appels de méthode par réflexion

  • Enter ou Lock.

  • Vérifications de sécurité. N’effectuez pas de demande, mais uniquement des demandes de liaison.

  • Isinst et Castclass pour les objets et proxys COM

  • Obtention ou définition de champs sur un proxy transparent.

  • Sérialisation.

  • Pointeurs de fonction et délégués.

Voir aussi

  • Last updated on