Compartilhar via


Regiões de execução restrita

Uma região de execução restrita (CER) é parte de um mecanismo para a criação de código gerenciado confiável. CER define uma área em que o common language runtime (CLR) é restrito para gerar exceções de out-of-band que impediriam que o código de área de execução em sua totalidade. Dentro dessa região, código do usuário é restrito de executar código resultaria no lançamento de exceções de out-of-band. O PrepareConstrainedRegions método deve preceder imediatamente uma try bloco e marcas catch, finally, e fault blocos como restrita regiões de execução. Depois de marcada como uma região restrita, o código só deve chamar outro código com contratos de confiabilidade forte e código não deve alocar ou fazer chamadas de virtuais para métodos não preparados ou não confiáveis, a menos que o código está preparado para lidar com falhas. O segmento de atrasos CLR aborta para o código que está executando em uma CER.

Regiões de execução restrita são usadas em diferentes formulários no CLR e um anotadas try Bloquear, notadamente finalizadores críticos em execução em classes derivadas da CriticalFinalizerObject classe e o código executado usando o ExecuteCodeWithGuaranteedCleanup método.

Preparação antecipada CER

O CLR prepara as CERs antecipadamente para evitar condições de falta de memória. Preparativos prévios são necessário para que o CLR não causa uma falta de condição de memória durante o carregamento de tipo ou compilação just-in-time.

O desenvolvedor é necessário para indicar que uma região de código é uma CER:

Restrições

Os usuários são restritos no tipo de código podem gravar em uma CER. O código não pode causar uma exceção de out-of-band, como pode resultar entre as seguintes operações:

  • Alocação explícita.

  • Boxing.

  • Adquirindo um bloqueio.

  • Chamando métodos despreparados virtualmente.

  • Chamando os métodos com um contrato de confiabilidade fraco ou inexistente.

No.NET Framework versão 2.0, essas restrições são diretrizes. O diagnóstico é fornecido por meio de ferramentas de análise de código.

Contratos de confiabilidade

O ReliabilityContractAttribute é um atributo personalizado que documenta a garante a confiabilidade e o estado de corrupção de um determinado método.

Garantias de confiabilidade

Garantias de confiabilidade, representadas por Cer valores de enumeração indicam o grau de confiabilidade de um determinado método:

  • MayFail. Sob condições excepcionais, o método pode falhar. Nesse caso, o método reporta novamente para o método de chamada se ele teve êxito ou falha. O método deve estar contido em uma CER para garantir que ele pode relatar o valor de retorno.

  • None. O método, tipo ou assembly não tem nenhum conceito de uma CER e não provavelmente seguro chamar dentro de uma CER sem redução substancial do dano de estado. Ele não aproveitar as garantias de CER. Isso envolve o seguinte:

    1. Sob condições excepcionais, o método pode falhar.

    2. O método pode ou não pode relatar que falhou.

    3. O método não é gravado para usar uma CER, o cenário mais provável.

    4. Se um método, tipo ou assembly não é identificado explicitamente tenha êxito, implicitamente é identificado como None.

  • Success. Sob condições excepcionais, o método certamente será bem-sucedido. Para atingir esse nível de confiabilidade, você sempre deve construir uma CER em torno do método que é chamado, mesmo quando ele é chamado de dentro de uma região de fora da CER. Um método é bem sucedido se ele realiza o que se destina, embora possa ser visualizado sucesso subjetiva. Por exemplo, a marcação de contagem com ReliabilityContractAttribute(Cer.Success) implica que quando ele é executado em uma CER, ele sempre retorna uma contagem do número de elementos de ArrayList e ele nunca pode deixar os campos internos em um estado indeterminado. No entanto, o CompareExchange método está marcado como sucesso, com o entendimento de sucesso pode significar que o valor não pode ser substituído por um novo valor devido a uma condição de corrida. O ponto principal é que o método se comporta da maneira que está documentado se comportar e código CER não precisa ser escrito para qualquer comportamento incomum, além do que o código correto mas não confiável seria de esperar.

Níveis de corrupção

Níveis de corrupção, representados por Consistency valores de enumeração indicam quanto do estado pode ser corrompida de um determinado ambiente:

  • MayCorruptAppDomain. Sob condições excepcionais, o common language runtime (CLR) faz com que não há garantias de consistência de estado no domínio do aplicativo atual.

  • MayCorruptInstance. Sob condições excepcionais, o método é garantido para limitar o dano de estado à instância atual.

  • MayCorruptProcessSob condições excepcionais, o CLR não garante sobre consistência de estado. ou seja, a condição pode corromper o processo.

  • WillNotCorruptState. Sob condições excepcionais, o método não irá corromper o estado.

Confiabilidade try/catch/finally

A confiabilidade try/catch/finally é uma exceção de manipulação de mecanismo com o mesmo nível de garantias de previsibilidade, como a versão não gerenciada. O catch/finally bloco é CER. Métodos no bloco exigem preparativos prévios e devem ser noninterruptible.

No.NET Framework versão 2.0, código informa o tempo de execução que um bloco try é confiável, chamando PrepareConstrainedRegions imediatamente anterior em um bloco try. PrepareConstrainedRegionsé um membro do RuntimeHelpers, um suporte de compilador classe. Chame PrepareConstrainedRegions diretamente pendentes sua disponibilidade por meio de compiladores.

Regiões de Noninterruptible

Uma região noninterruptible agrupa um conjunto de instruções em uma CER.

No.NET Framework versão 2.0, havendo disponibilidade por meio de suporte do compilador, o código de usuário cria regiões não passível de interrupção com um confiável try/catch/finally que contém um bloco try/catch vazio precedido por um PrepareConstrainedRegions chamada de método.

Objeto do finalizador crítico

A CriticalFinalizerObject garante que a coleta de lixo executará o finalizador. Após a alocação, o finalizador e seu gráfico de chamada são preparados antecipadamente. O método do finalizador é executado em uma CER e deve obedecer a todas as restrições nas CERs e finalizadores.

Tipos que herdam SafeHandle e CriticalHandle garante ter seu finalizador executado dentro de uma CER. Implementar ReleaseHandle em SafeHandle derivadas de classes para executar qualquer código que é necessária para liberar o identificador.

Código não é permitido nas CERs

As operações a seguir não são permitidas nas CERs:

  • Alocações explícitas.

  • Adquirindo um bloqueio.

  • Boxing.

  • Acesso à matriz multidimensional.

  • Método chama-se através de reflexão.

  • Enter ou Lock.

  • Verificações de segurança. Não realizar demandas, apenas a demandas de link.

  • Isinste Castclass para objetos COM e proxies

  • Obter ou definir o campos em um proxy transparente.

  • Serialização.

  • Os ponteiros de função e delegados.

Consulte também

Conceitos

As práticas recomendadas de confiabilidade