Condividi tramite

Aree di esecuzione vincolate

Un'area di esecuzione vincolata fa parte di un meccanismo per la creazione di codice gestito affidabile. Un CER definisce un'area in cui il runtime di linguaggio comune (CLR) è vincolato dal lancio di eccezioni fuori banda che impediscono l'esecuzione del codice nell'area nel suo insieme. All'interno di tale area, il codice utente è vincolato dall'esecuzione di codice che provocherebbe la generazione di eccezioni fuori banda. Il PrepareConstrainedRegions metodo deve precedere immediatamente un try blocco e contrassegna catchi blocchi , finallye fault come aree di esecuzione vincolate. Dopo aver contrassegnato come area vincolata, il codice deve chiamare solo altro codice con contratti di affidabilità avanzata e il codice non deve allocare o effettuare chiamate virtuali a metodi non preparati o non affidabili, a meno che il codice non sia pronto a gestire gli errori. CLR ritarda l'interruzione dei thread per il codice in esecuzione in un CER.

Importante

CER è supportato solo in .NET Framework. Questo articolo non si applica a .NET Core o .NET 5 e versioni successive.

Le aree di esecuzione vincolate vengono usate in forme diverse nel CLR oltre a un blocco con annotazioni try, in particolare i finalizzatori critici in esecuzione nelle classi derivate dalla classe CriticalFinalizerObject e il codice eseguito usando il metodo ExecuteCodeWithGuaranteedCleanup.

Preparazione avanzata CER

CLR prepara in anticipo le richieste di archiviazione per evitare condizioni di memoria insufficiente. La preparazione preventiva è necessaria affinché la CLR non causi un esaurimento della memoria durante la compilazione just-in-time (JIT) o il caricamento dei tipi.

Lo sviluppatore deve indicare che un'area del codice è un'area di controllo:

Vincoli

Gli utenti sono vincolati nel tipo di codice che possono scrivere in un'area a esecuzione vincolata. Il codice non può causare un'eccezione fuori banda, ad esempio potrebbe derivare dalle operazioni seguenti:

  • Allocazione esplicita.

  • Boxe.

  • Acquisizione di un blocco.

  • Chiamare metodi non preparati virtualmente.

  • Chiamare metodi con un contratto di affidabilità debole o inesistente.

In .NET Framework versione 2.0 questi vincoli sono linee guida. La diagnostica viene fornita tramite gli strumenti di analisi del codice.

Contratti di affidabilità

ReliabilityContractAttribute è un attributo personalizzato che documenta le garanzie di affidabilità e lo stato di danneggiamento di un determinato metodo.

Garanzie di affidabilità

Garanzie di affidabilità, rappresentate da Cer valori di enumerazione, indicano il grado di affidabilità di un determinato metodo:

  • MayFail. In condizioni eccezionali, il metodo potrebbe non riuscire. In questo caso, il metodo restituisce al metodo chiamante se ha avuto esito positivo o negativo. Il metodo deve essere contenuto in un CER per garantire che possa riportare il valore restituito.

  • None. Il metodo, il tipo o l'assembly non ha alcun concetto di CER e probabilmente non è sicuro chiamare all'interno di un CER senza una sostanziale mitigazione della corruzione dello stato. Non sfrutta le garanzie CER. Questo implica quanto segue:

    1. In condizioni eccezionali il metodo potrebbe non riuscire.

    2. Il metodo potrebbe o non segnalare che non è riuscito.

    3. Il metodo non è progettato per utilizzare un CER, che è lo scenario più probabile.

    4. Se un metodo, un tipo o un assembly non viene identificato in modo esplicito per avere esito positivo, viene identificato in modo implicito come None.

  • Success. In condizioni eccezionali, il metodo ha la certezza di avere esito positivo. Per ottenere questo livello di affidabilità, è consigliabile costruire sempre un cer intorno al metodo chiamato, anche quando viene chiamato dall'interno di un'area non CER. Un metodo ha esito positivo se esegue ciò che è previsto, anche se il successo può essere considerato soggettivamente. Ad esempio, contrassegnare Count con ReliabilityContractAttribute(Cer.Success) implica che quando viene eseguito in un CER (Common Execution Runtime), restituisce sempre un conteggio del numero di elementi in ArrayList e non può mai lasciare i campi interni in uno stato indeterminato. Tuttavia, anche il CompareExchange metodo è contrassegnato come esito positivo, con l'intesa che l'esito positivo potrebbe significare che il valore non può essere sostituito con un nuovo valore a causa di una condizione di gara. Il punto chiave è che il metodo si comporta nel modo in cui si comporta e il codice CER non deve essere scritto per aspettarsi un comportamento insolito oltre al codice corretto ma non affidabile.

Livelli di corruzione

I livelli di danneggiamento, rappresentati da Consistency valori di enumerazione, indicano quanto stato può essere danneggiato in un determinato ambiente:

  • MayCorruptAppDomain. In condizioni eccezionali, Common Language Runtime (CLR) non garantisce la coerenza dello stato nel dominio applicazione corrente.

  • MayCorruptInstance. In condizioni eccezionali, il metodo garantisce di limitare la corruzione dello stato all'istanza corrente.

  • MayCorruptProcess, in condizioni eccezionali, il CLR non garantisce la consistenza dello stato. Ovvero, la condizione potrebbe danneggiare il processo.

  • WillNotCorruptState. In condizioni eccezionali, è garantito che il metodo non danneggi lo stato.

Gestione errori con try/catch/finally di affidabilità

L'affidabilità try/catch/finally è un meccanismo di gestione delle eccezioni con lo stesso livello di garanzie di prevedibilità della versione non gestita. Il catch/finally blocco è il CER. I metodi nel blocco richiedono preparazione anticipata e devono essere non interrompibili.

In .NET Framework versione 2.0 il codice informa il runtime che un tentativo è affidabile chiamando PrepareConstrainedRegions immediatamente prima di un blocco try. PrepareConstrainedRegions è un membro di RuntimeHelpers, una classe di supporto del compilatore. Chiamare PrepareConstrainedRegions direttamente, in attesa della sua disponibilità tramite i compilatori.

Aree non interruptibili

Un'area non interruptibile raggruppa un set di istruzioni in una Regione di Esecuzione Vincolata.

In .NET Framework versione 2.0, con disponibilità prevista tramite supporto del compilatore, il codice utente crea aree non interrompibili usando un try/catch/finally affidabile che contiene un blocco try/catch vuoto preceduto da una chiamata al metodo PrepareConstrainedRegions.

Oggetto Finalizzatore Critico

Garantisce CriticalFinalizerObject che il finalizzatore venga eseguito da Garbage Collection. Al momento dell'allocazione, il finalizzatore e il relativo grafico di chiamata vengono preparati in anticipo. Il metodo finalizzatore viene eseguito in un CER e deve rispettare tutti i vincoli relativi ai CER e ai finalizzatori.

Tutti i tipi che ereditano da SafeHandle e CriticalHandle sono garantiti di avere il loro finalizzatore eseguito all'interno di una Regione di Esecuzione Vincolata (CER). Implementare ReleaseHandle nelle SafeHandle classi derivate per eseguire qualsiasi codice necessario per liberare l'handle.

Codice non consentito nei CERs

Le operazioni seguenti non sono consentite nei CERs:

  • Allocazioni esplicite.

  • Acquisizione di un blocco.

  • Boxe.

  • Accesso alla matrice multidimensionale.

  • Il metodo chiama tramite reflection.

  • Enter o Lock.

  • Controlli di sicurezza. Non eseguire richieste, ma solo richieste di collegamento.

  • Isinst e Castclass per oggetti e proxy COM

  • Recupero o impostazione di campi in un proxy trasparente.

  • Serializzazione.

  • Puntatori di funzione e delegati.

Vedere anche