C# 演示受约束执行区域重要性的代码

除非应用了

[ReliabilityContract（consistence.WillNotCorruptState，Cer.Success）]

，否则是否有人可以创建一个中断的短样本

---

我只是浏览了一下，无法将其破坏，即使我注释掉了ReliabilityContract属性。最后似乎总是接到电话

虽然我没有一个具体的例子给你，但我认为你错过了“尝试”的重点。最后，在保证成功的方法中插入一些。说该方法将始终成功的关键在于，考虑到执行期间发生了什么（异常），将采取步骤确保在该方法返回时所访问的数据将处于有效状态。最后，如果没有尝试，您将无法确保任何事情，并且可能意味着您希望进行的操作只有一半会进行。因此，Cer.Success实际上并不能保证成功，它只表明您作为开发人员保证了成功

---

查看此页面，了解与数组相关的成功和可能失败状态之间的差异。CopyTo方法：

CER属性是文档的一种方式。它们确实会影响CLR在某些情况下执行代码的方式，但我相信它们（或缺少它们）在当前的.NET版本中永远不会导致错误

---

它们大部分是“保留供将来使用的”。

您是否在调试器下运行MSDN示例？我认为在调试器中执行时，CER不可能运行，因为调试器本身会改变执行的性质

---

如果您以优化的发布模式构建并运行应用程序，您应该能够看到它失败。

此功能的主要驱动程序是支持SQL Server将CLR集成到SQL Server 2005中的严格要求。可能是为了其他人可以使用，也可能是出于法律原因，这种深度集成是作为托管API发布的，但技术要求是SQL Server。请记住，在SQL Server中，MTBF是以月而不是小时为单位度量的，并且由于发生未处理的异常而重新启动进程是完全不可接受的

这可能是我见过的描述受约束执行环境的技术需求的最好的一个

ReliabilityContract用于修饰方法，以指示它们在潜在异步异常（ThreadAbortException、OutOfMemoryException、StackOverflowException）方面的操作方式。受约束的执行区域定义为try块的catch或finally（或fault）部分，该部分前面紧接着调用System.Runtime.CompilerServices.RuntimeServices.PrepareConstrainedRegions（）

当从CER中使用可靠性合同方法时，会发生两件事。该方法将由JIT预先准备好，以便它不会在第一次执行时调用JIT编译器，这可能会试图使用内存本身并导致它自己的异常。此外，在CER内部，运行时承诺不会引发ThreadAbort异常，并将等待引发异常，直到CER完成

回到你的问题上来；我仍在尝试提供一个简单的代码示例，它将直接回答您的问题。正如您可能已经猜到的，考虑到问题的异步性质，最简单的示例将需要相当多的代码，并且很可能是SQLCLR代码，因为这是使用CER获得最大好处的环境

using System;
using System.Runtime.CompilerServices;
using System.Runtime.ConstrainedExecution;

class Program {
    static bool cerWorked;

    static void Main( string[] args ) {
        try {
            cerWorked = true;
            MyFn();
        }
        catch( OutOfMemoryException ) {
            Console.WriteLine( cerWorked );
        }
        Console.ReadLine();
    }

    unsafe struct Big {
        public fixed byte Bytes[int.MaxValue];
    }

    //results depends on the existance of this attribute
    [ReliabilityContract( Consistency.WillNotCorruptState, Cer.Success )] 
    unsafe static void StackOverflow() {
        Big big;
        big.Bytes[ int.MaxValue - 1 ] = 1;
    }

    static void MyFn() {
        RuntimeHelpers.PrepareConstrainedRegions();
        try {
            cerWorked = false;
        }
        finally {
            StackOverflow();
        }
    }
}

当MyFn被jitted时，它尝试从finally块创建一个ConstrainedRegion

• 在没有ReliabilityContract的情况下，无法形成适当的约束区域，因此会发出常规代码。调用Stackoverflow时抛出堆栈溢出异常（在执行try块之后）

• 在可靠性合同的情况下，可以形成一个约束区域，并且可以将finally块中方法的堆栈要求提升到MyFn中。堆栈溢出异常现在在调用MyFn时抛出（在try块执行之前）

---

CER主要用于保护托管CLR在appdomain断开和其他异常情况下不受损坏状态的影响。SQL Server之类的主机可能会触发粗暴中止，在粗暴中止期间，finally子句可能会中断。更明确一点，CER允许开发人员编写代码，在异常情况下保护自己不损坏自己的状态。CER并没有保护CLR的固有特性，它只是使编写能够保护自身的代码成为可能。肮脏的秘密是在CLR 1.0/1.1中，不可能编写能够成功处理某些类别的异常的代码。链接已断开。尽管投票结果是否定的，但这个问题缺乏示例证明了我的观点。CER不会影响代码流，包括finally块。它们记录代码，以便框架可以区别对待。基本上，它可以翻译为“我不会提出异步异常，你不会用异步异常打断我”。从统计上看，删除CER不会破坏代码，尽管它可能会降低可靠性。很明显，CER可以用于比当前运行时实现的功能多得多的功能；当在受约束的执行区域内使用时，JIT将在执行前准备一个标记为ReliabilityContract的方法进行预编译，并在进入PrepareConstrainedRegions时预分配该方法的内存。它们是文档。该文档由CLR阅读和使用，正如我也说过的，这里没有矛盾。关键是，“除非应用[]，否则短样本将中断”是不可能的，没有CER属性，任何东西都不会中断。变得不那么可靠

using System;
using System.Runtime.CompilerServices;
using System.Runtime.ConstrainedExecution;

class Program {
    static bool cerWorked;

    static void Main( string[] args ) {
        try {
            cerWorked = true;
            MyFn();
        }
        catch( OutOfMemoryException ) {
            Console.WriteLine( cerWorked );
        }
        Console.ReadLine();
    }

    unsafe struct Big {
        public fixed byte Bytes[int.MaxValue];
    }

    //results depends on the existance of this attribute
    [ReliabilityContract( Consistency.WillNotCorruptState, Cer.Success )] 
    unsafe static void StackOverflow() {
        Big big;
        big.Bytes[ int.MaxValue - 1 ] = 1;
    }

    static void MyFn() {
        RuntimeHelpers.PrepareConstrainedRegions();
        try {
            cerWorked = false;
        }
        finally {
            StackOverflow();
        }
    }
}