我正在通读 Constrained Execution Regions and other errata [Brian Grunkemeyer]试图理解受约束的执行区域,但是我在理解以下示例时遇到了一些问题:
RuntimeHelpers.PrepareConstrainedRegions();
try {
// Prepare my backout code
MethodInfo m = _list.GetType().GetMethod("RemoveAt", new Type[] { typeof(int) });
RuntimeHelpers.PrepareMethod(m.MethodHandle);
IEnumerator en = c.GetEnumerator();
while(en.MoveNext()) {
_list.Insert(index++, en.Current);
// Assuming that these lines aren't reordered.
numAdded++;
}
_version++;
}
catch(Exception) {
// Reliable backout code
while(numAdded > 0) {
_list.RemoveAt(index--);
numAdded--;
}
throw;
}
我的理解是 try
block 不受约束,只有 finally 和 catch block 受到约束。这意味着在 try
block 期间,可以随时抛出异步异常(例如 ThreadAbortException),特别是它可以在 numAdded++
之前但在 _list 之后抛出。插入
。在这种情况下,撤销代码将从 _list
中删除太少的一项。
鉴于此,我很难理解此示例中受限执行区域的用途。
我对此的理解正确还是我错过了什么?
最佳答案
根据我的观察,文档和 CER 的实际行为并不完全匹配。您描述的问题是 ThreadAbortException
在 Insert
和 numAdded++
之间被注入(inject)的问题对于我测试过的任何 .NET Framework 版本都是不可能的。这有两个可能的原因。
PrepareConstrainedRegions
确实,不管文档怎么说,对try
block 有明显的影响。它会延迟某些中止注入(inject);特别是那些在线程处于可警报状态时不会出现的线程。- 即使没有
PrepareConstrainedRegions
调用,abort 仍然不会注入(inject)到该位置。基于 SSCLI 代码,将在向后跳转时注入(inject)中止以旋转while
循环。
我在回答自己的相关 question here 时想通了其中的一些内容然后尝试回答有关 Thread.Abort
实际如何工作的问题 here .
第 2 点不合法。它是 SSCLI 的一个实现细节,可能不会转移到官方发行版(尽管我怀疑它确实会转移)。此外,它忽略了在 Insert
执行期间的某个时刻注入(inject)中止的可能性。我想 Insert
的关键部分可能会在内部使用 CER。
第 1 点可能是最重要的一点,但这引出了微软为什么没有记录它以及为什么你引用的文章也没有提到它的问题。这篇文章的作者当然知道这个事实。否则,我也不明白所提供的代码如何可能是安全的。换句话说,现在似乎只是偶然才安全。
如果我不得不猜测 PrepareConstrainedRegions
在幕后做了什么,我会说它在 JIT 引擎中设置了一个标志,告诉它不要注入(inject)获取的 GC 轮询 Hook 策略性地放置在 CER try
block 内代码的向后分支跳转处。这个 GC 轮询 Hook 是通常注入(inject)异步中止的地方(除了与垃圾收集相关的主要目的之外)。
关于c# - 了解此示例中 CER 的用途,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/7834110/