views:

69

answers:

1

MSDN documentation suggests that there may be other ways of using ExitContext flag. See WaitHandle.WaitOne() What other ways are there to enter a non-default context outside of using a ContextBoundObject inherited class? (I can't use ContextBoundObject in my application)

+1  A: 

The clue is in this sentence.

Even if you are currently executing a method on a class that does not derive from ContextBoundObject, like String, you can be in a nondefault context if a ContextBoundObject is on your stack in the current application domain.

So basically you could call WaitOne from within a class that does not subclass ContextBoundObject nor would you have any preconceived notion that a ContextBoundObject was in any way involved with your code and yet the thread in question could be in a nondefault context because somewhere way up in the call stack an instance method of a ContextBoundObject class could be running unbeknown to you.

Outside of that lone exception there are no other ways of entering into a nondefault synchronization context.

There is a pretty good article on threading with additional information related to synchronization contexts which can be found here.

Brian Gideon
Thanks for posting that. Although, apparently you can use ContextAttribute as well http://msdn.microsoft.com/en-us/library/system.runtime.remoting.contexts.contextattribute.aspx. I still haven't been able to use it or see an example of how it's used without ContextBoundObject.
MandoMando
I'll have to be honest here. I am not familiar with `ContextAttribute` nor how it would be used.
Brian Gideon
That's makes two of us ;) Perhaps someone will shed more light on ContextAttribute. I think I have to post a new question regarding what scenarios constitute a non-default context.
MandoMando