Take a simple look at the source code of ThreadPool and the other way to see the threads Pass value

These days too busy no time to write a blog, go home today simply look at the next ThreadPool source, found that there is a fun thing, called "Execution context", the name is called: "ExecutionContext".

A: The approximate flow of threadpool.

The first step: it calls the underlying helper method.

Step two: Walk into this helper method, we will find a queue, and the item of this queue must be an instance of Queueuserworkitemcallback, and then this will inspire my

Interest, see what queueuserworkitemcallback have in the end?

Step three: When you go to the Queueuserworkitemcallback instance, the Callback,state parameter is given to the field of the current class, and there is a fun place that is based on

Executioncontext.isflowsuppressed () to determine if the "current thread's context" should be given to the "calling thread"? This is put in the back and then we see a

A Ithreadpoolworkitem.executeworkitem () method, which has a contextcallback delegate call, perhaps this is the queue in each item to be called

The method.

Fourth step: Then we go back to the second step of the ThreadPoolGlobals.workQueue.Enqueue (callback, True) method to look inside, and our callback,state are encapsulated into

Queueuserworkitemcallback put in the queue, from this enqueue method, we see a this. Ensurethreadrequested (), go inside the method.

of , this is an urgent need to see the Threadpool.requestworkerthread () method, but it is an extern method, but from the name of the request worker thread to execute, so and

There is no real discovery to the so-called thread pool of this thing. (It may not be right to have a glimpse of the whole picture.)

Well, the above analysis is probably the case, in fact, all the methods are encapsulated into the bottom of a class placed in a queue, should be using the above for to select the idle worker to execute our

The task, there are many code, more complex, for a moment also can not understand what.

Two: Execution context

The third step is the "execution context", see this method inside there is an if condition, and then see there is a executioncontext.isflowsuppressed () method, from the name

It can be seen that "stop the flow", if not, use capture to grasp the current thread's "contextual information", and then we take a look down, from this method, we sequentially

To fetch the "security settings" of the calling thread, "host Settings", "Synchronize Information", "Logical call", and you can see that LogicalCallContext has a value, it will do a copy operation.

Actually this logicalcallcontext very interesting, inside is a KV structure, the source also said, as long as I do not isflowsuppressed, then the main thread of the context will flow to

Worker threads, so how do you set LogicalCallContext? In fact, in C # inside the CallContext inside of Logicalsetdata and logicalgetdata can do these things.

1     class Program2     {3         Static voidMain (string[] args)4         {5Callcontext.logicalsetdata ("name","Ctrip");6 7Thread.CurrentThread.IsBackground =true;8 9ThreadPool.QueueUserWorkItem ((o) =Ten             { One                 vart =Thread.CurrentThread.ManagedThreadId; A  -               var result = Callcontext.logicalgetdata ("name"); -  theConsole.WriteLine ("I am a worker thread: Name:"+result); -  -             }); -  + Console.read (); -         } +}

Can see I set the value in the main thread is read by the worker thread, is not very interesting, give us the line threads Pass value provides another way, just we also see, once isflowsuppressed

, then the context returns NULL, which prevents the Logiccallcontext information from being passed to the worker thread, which can be done with Executioncontext.suppressflow (), with the following specific

Take a look at it.

1   class Program2     {3         Static voidMain (string[] args)4         {5Callcontext.logicalsetdata ("name","Ctrip");6 7             //block Logical Data Flow8 Executioncontext.suppressflow ();9 TenThread.CurrentThread.IsBackground =true; One  AThreadPool.QueueUserWorkItem ((o) = -             { -                 vart =Thread.CurrentThread.ManagedThreadId; the  -                 varresult = Callcontext.logicalgetdata ("name"); -  -Console.WriteLine ("I am a worker thread: Name:"+result); +  -             }); +  A Console.read (); at         } -}

Now the conclusion also comes out, go to capture the main thread of the context is need a lot of code amount, so if the worker thread does not use the main thread of this information, then you should do show off, so

There is a great benefit to the performance of the worker thread.

Take a simple look at the source code of ThreadPool and the other way to see the threads Pass value