ExecutionContext of Threads ExecutionContext of Threads multithreading multithreading

ExecutionContext of Threads


The details of ExecutionContext are very obscure, buried deep inside features like .NET Remoting and WCF.What is part of it is:

  • HostExecutionContext
  • IllogicalCallContext, a repository of thread specific data used by Remoting
  • LogicalContext, as above
  • SecurityContext
  • SynchronizationContext

CultureInfo is not part of it, which can be a considerable problem if you change your main thread's default culture. There is no good way to ensure other threads run with that culture unless you explicitly write the code to switch them. That's not always practical, given that .NET is apt to run async callbacks on threadpool threads. They will be initialized to the system default culture.

Edit: this problem got fixed in .NET 4.5 with the CultureInfo.DefaultThreadCurrentCulture property.

Edit2: fixed much more thoroughly in .NET 4.6, culture now flows as expected.


ExcecutionContext.SuppressFlow suppresses the flow of the execution context across asynchronous threads.

The ExecutionContext, are implicitly passed from parent thread to the child one, provides information relevant to a logical thread of execution: security context, call context and synchronization context. If that information is not imperative, the omission of the execution context optimize a little the performance of a multithreading application.

ExecutionContext.RestoreFlow restores the passage of the execution context between threads.

Finally

Q: In the following code what exactly gets suppressed??

A: Exactly are suppressed the passage of the following information: security context, call context and synchronization context; between the newly created threads. Why that was do? -To optimize the creation and work of th.Length created threads: less supplementary information passed between threads - quicker this threads interact between them.


Not the answer to your question, but since you're looking at this code and try to understand it right now, please check if you want to adapt/change your code according to the documentation (i.e. "fix it"):

ExecutionContext.SuppressFlow:

You must use the Undo method on the returned AsyncFlowControl structure to restore the flow of the ExecutionContext.

ExecutionContext.RestoreFlow:

RestoreFlow reverses the effect of a prior SuppressFlow method call.

This method is called by the Undo method of the AsyncFlowControl structure returned by the SuppressFlow method. You should use the Undo method to restore the flow of the execution context, not the RestoreFlow method.

Emphasis mine.