Monitor.Wait 和“exitContext”范围
MSDN 文档提到“exitContext”布尔参数：
true 退出并重新获取 上下文的同步域 （如果在同步上下文中）之前 等待；否则为假。
我不跟。假设我已经了解脉冲和等待，任何人都可以给出这个参数的手持解释吗？其使用的实际示例将非常有价值。
The MSDN documentation says of the "exitContext" boolean parameter:
true to exit and reacquire the
synchronization domain for the context
(if in a synchronized context) before
the wait; otherwise, false.
I don't follow. Assuming I already understand pulse and wait, can anyone give a hand-holding explanation of this parameter? A practical example of its use would be quite valuable.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这是 .net 框架中一个非常古老的问题；只需传递 false 并继续。
他们所指的“上下文”是远程处理上下文。您可以尝试通过在 MSDN 中查找 ContextBoundObject 来理解这个概念；这将引导您发现各种有趣的东西。在 CLR 设计的某个时刻，这些“对象上下文”将比它们实际最终变得重要得多；许多人忘记了它们最初的存在，大多数人遇到的唯一与 CBO 有关的 API 是 Monitor.Wait。
所以只需传入 false 并继续。 :)
如果您愿意，我们可以更深入...
有一个概念是将这些对象上下文之一配置为“同步”。事实证明，在 CLR 中，每个线程都有一个与其关联的逻辑调用上下文。当您使用远程处理进行方法调用时，此逻辑调用上下文会与调用一起传递，以便远程处理边界另一侧的 CLR 可以将处理请求的线程视为逻辑上相同的线程。如果被调用的对象（远程处理边界另一侧的对象）回调到原始对象，则第二次调用可能位于不同的物理线程上。但是，由于逻辑调用上下文与远程调用一起流动，因此第二个物理线程可以重新进入“同步”上下文。
这个例子太复杂了，无法在这里写出来。我可以根据需要为您编写一个，但是...
这是 .net 框架中的一个非常古老的问题；只需传递 false 并继续。 :)
It's a very old wart in the .net frameworks; just pass in false and move on.
The "context" they are referring to is a remoting context. You can try to run down that concept by looking up ContextBoundObject in MSDN; this will lead you to all sorts of interesting stuff. At one point in the design of the CLR these "object contexts" were going to be a lot more important than they actually ended up being; many people forgot they existed in the first place, and the only API most people ever encounter that has anything to do with CBOs is Monitor.Wait.
So just pass in false and move on. :)
We can go even deeper if you want...
There was a notion of configuring one of these object contexts to be "synchronized". It turns out that in the CLR, every thread has a logical call context associated with it. When you make a method call with remoting, this logical call context is passed along with the call, so that the CLR on the other side of the remoting boundary can treat the thread processing the request as being logically the same thread. If the object being called (the one on the other side of the remoting boundary) calls back into the original object, then that second call may be on a different physical thread. However, because the logical call context flowed along with the remoting call, that second physical thread can re-enter the "synchronized" context.
An example of this is far to complex to try to write out here. I can write one for you on demand, but...
It's a very old wart in the .net frameworks; just pass in false and move on. :)
它与远程处理场景相关，传递 true 允许传递另一个调用。这个完全相同的论点也是将 WaitHandle.WaitOne(int) 重载添加到 .NET 2.0 SP1 的原因。兼容性的破坏性变化导致了很多痛苦。以前只有 WaitOne(int, bool) 重载可用，没有人知道 exitContext 参数的含义。
传递 false 是正常用法。我认为自己对任何使用 true 可能有意义或取得良好结果的实际例子一无所知。远程处理的核心相当复杂且文档很少。 WCF 让它变得无关紧要。
It is relevant in remoting scenarios, passing true allows another call to be delivered. This exact same argument was also the reason that the WaitHandle.WaitOne(int) overload was added to .NET 2.0 SP1. A compatibility breaking change that caused plenty of misery. Previously only the WaitOne(int, bool) overload was available and nobody knew what that exitContext argument meant.
Passing false is the normal usage. I count myself pleasantly ignorant of any practical example where using true could either make sense or come to a good end. Remoting is at its core quite complicated and poorly documented. WCF made it irrelevant.