https://blog.csdn.net/wsxqaz/article/details/9083093
Recently we need to develop a transaction management tool, something to help developers manage affairs (for example, do not they shut up connection), necessary to use this context to call, so he found a related article. You can also learn about
http://blog.sina.com.cn/s/blog_7325e5ea0100orc9.html
Some time ago just to be open on a page of a multi-threaded program attempts to invoke multiple components, these components are developed by other teams (such as: India / Russia), so modify their code is not very realistic look However, annoying is that a lot of their code uses AppContext.Current this object (actually used HttpContext.Current.Item to store), and once asynchronous, HttpContext.Current ceased to exist, naturally will keep reported null reference exception, it seems the asynchronous is not realistic.
Just when a last resort, suddenly found a strange class called CallContext of hiding in System.Runtime.Remoting.Messaging few people use this namespace below, of course, just the beginning I was attracted by its name, literal translation is not the calling context it? This thing can feel a little effect. Now then the msdn, described as follows:
Attribute set to provide transmitted together with the code execution path. It can not be inherited.
Nonsense. . . See Note it:
CallContext dedicated collection object thread local storage similar to the method call, and provides the data for each logical channel are unique execution thread. Data sharing between the grooves does not call on other logical thread contexts. When CallContext execution code along the path of the round trip propagation path and checks the individual objects, which can be added to an object.
When another object in the AppDomain remote method invocation, CallContext LogicalCallContext class instance will generate a propagating together with the remote call. Only the interface objects disclosed ILogicalThreadAffinative CallContext and stored in the AppDomain is propagated to the outside LogicalCallContext. This interface does not support the object is not transmitted together with the remote method invocation instances LogicalCallContext.
It seems there is something there, but define the logical thread seems there are so ambiguous, however, also mentioned an interface ILogicalThreadAffinative, look at this interface defines what a look member definitions. . . No members. . . An empty port, a handful of sweat, or look on msdn how to describe it:
AppDomain marker can be propagated to the outside of the object LogicalCallContext.
He emphasized the role of the remoting, and then look Note:
When another object in the AppDomain remote method call, a class generator current CallContext propagated along with the call to the remote location LogicalCallContext. Only public ILogicalThreadAffinative interfaces and objects stored in CallContext AppDomain are propagated to the outside. This interface does not support the object is not transmitted together with the remote method invocation instances LogicalCallContext.
Also emphasized the role remoting, it is envisioned that, with substantially similar isILogicalThreadAffinative CallContext way to discriminate different objects, in line with respect to this interface will be placed LogicalCallContext, without additional matching process.
From the perspective of the document, what seems to have been no progress, and this time, suddenly thought of a previously seen very interesting type ExecutionContext, namespace is System.Threading, looks multithreaded prepared, however, say the example on msdn the problem of how to control the transfer of the rights object, and how it comes to pass no ordinary objects.
A moment think of the so-called LogicalCallContext which would not exist in ExecutionContext in? I checked msdn, see Note:
ExecutionContext class for all information related to a thread of execution logic provides a single container. This includes the security context, call context and synchronization context.
ExecutionContext class provides functionality allows the user code can be captured and transmitted in this context between an asynchronous user-defined point. The common language runtime to ensure consistency between asynchronous transfer ExecutionContext point run in the hosting process defined by the library.
Managed execution context is equivalent unit COM. In the application domain, whenever the transmission thread must transfer the entire execution context. By Thread .. ::. Start method, most operating and Windows Forms thread pool threads by marshaling Windows message pump resulting in the transmission process, this situation will occur. Unsafe operation in thread pool (e.g. UnsafeQueueUserWorkItem method) does not occur in this case, because the thread pool unsafe operation does not transmit the compressed stack. Whenever the flow of compressed stack, hosted body, synchronization, locale and the user context also will flow. Capture and CreateCopy ExecutionContext class provides methods to obtain the execution context, and providing the Run method to set the current thread of execution context.
ExecutionContext associated can not be set on another thread with a thread. Attempting to do so will result in an exception is thrown. To ExecutionContext spread from one thread to another, make a copy of ExecutionContext.
ExecutionContext all the data in the internal storage associated with LogicalCallContext. This makes it possible to spread the data at LogicalCallContext copy and transfer ExecutionContext.
Sure enough, ExecutionContext there is data LogicalCallContext, and well illustrated, both Thread.Start or use the thread pool for most operations, ExecutionContext will automatically transfer the data to those threads (about ThreadPool.UnsafeQueueUerWorkItem method used to believe that people should not many), it seems the actors are in attendance, they can immediately perform a multithreaded good show.
First, plays a key role ExectionContext, maybe we do not need to code it figure appeared, but that is only because the method .net class library, as well we encapsulate this functionality, without it, I would like to put in a thread an object tells another thread, it is only through the heap.
Secondly, LogicalCallContext, the object of many ExecutionContext spread, many of which are beyond our simple use (can not spread to an object, to define the rights of a custom bar), and custom objects LogicalCallContext is the best carrier.
Finally, the remaining question is how to read and write LogicalCallContext problem, finally turn CallContext is played. CallContext ready to look at what our method: GetData, SetData, LogicalGetData, LogicalSetData, FreeNamedDataSlot, GetHeader, SetHeader and HostContext property.
The first focus, of course, is the GetData and SetData these two methods, made a simple test, found that the two methods, that is, indeed to decide whether or not to grant a new target thread by ILogicalThreadAffinative interface, and delete this data method is FreeNamedDataSlot, now as long as every empty interface to add a multi-threaded objects that are common to, and before the start of multi-threading in the main thread in the target set in, and then taken out in other threads can get to the problem a. After the multi-threaded part, do not forget to use FreeNamedDataSlot to delete it.
I do not know if you noticed, the GetData and SetData outside, a pair of LogicalGetData and LogicalSetData, both of which are used to do? Is the Logical and LogicalCallContext have anything to do what?
Again in front of the simple experiment a bit to do, just in a LogicalGetData and LogicalSetData these two methods, concludes that regardless of whether to implement ILogicalThreadAffinative interface objects can be accessed in the new thread, which means you can now transmit any data to the new thread, including string .net defined, int and other basic types, this program has been close to perfect.
Look back at my task bar, you only need to change the implementation AppContext.Current attributes, and before and after the start of multi-threading to do a little processing, other components can be run concurrently intact in their respective on the thread.
Things work ends here.
In it he said CallContext.HostContext property is doing, through a simple test and found that in Asp.net program, which put this HostContext is an example of HttpContext, ms lazy enough. In fact ms just do a little modification, multi-threaded Asp.net would not have too much trouble, just HttpContext realize what ILogicalThreadAffinative interfaces, no matter how many threads to open to the other side to be able to access HttpContext.Current, of course, ms did not do so for a reason, once HttpContext spread to other threads, it is difficult to control the life cycle asp.net HttpContext object, and the object HttpContext and HttpRequest object reference to this, the side effects may be greater than imagined large much more.