Monitor.Wait and the "exitContext" Parameter

Question

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.

Answer 1

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. :)

Answer 2

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.