ExecutionContext vs SynchronizationContext

re: ExecutionContext vs SynchronizationContext

Sean Hanna — Fri, 19 Apr 2013 18:41:21 GMT

It would be interesting to see some more in-depth discussion of how to properly attach data to an execution context using LogicalCallContext.LogicalSetData / LogicalGetData

I recently was doing this to capture some application specific context data that needs to flow across thread boundaries. Context data like 'username' from a forms / custom authentication mechanism, internal id's, performance metrics, etc.. are all useful data to attach to a thread but it's so low-level that doing so is intimidating.

Using context like this for application code is an architectural nightmare (service locator), but trying to do parameter / constructor injection of stuff like the username when your code wasn't built out to do this originally is a nightmare too.

The LogicalCallContext is a Dictionary<object,object> but only performs a shallow copy on the key/value data stored inside this dictionary.

There is a special hardcoded case for using ICloneable when flowing the ETW ActivityID but otherwise nothing can be flowed using a deep copy.

It seems that it is possible that Logical Call Context data is flowed 'backwards' into an invoking process (or as a result of some other trickery going on) because, for example, when using LogicalCallContext in an MSTest unit test, if you leave a reference to an object of a custom type in the context when the test terminates, the object ends up in the mstest.exe process space, it attempts to resolve this type name, and if the dll that declares the type isn't readily available in the GAC or AssemblyLoadPath then mstest crashes.

There are also several references on the internet citing problems with the way LogicalCallContext is flowed between thread pool threads by IIS which is an outstanding concern that i chose to ignore because async / flowing threads in IIS is not something we are doing intentionally right now, the happy-path works for us, and this application can afford that kind of assumption.

Is the logical call context actually being guaranteed to flow data properly? Would an IIS threadpool not doing so be a bug? Are there other important risks to be aware of?

After dealing with all these problems i ended up having to create custom implementations of IDictionary<> / ISet<> / IList<> that use LogicalCallContext as a backing data store, so that the buckets are deep-copied when the context is flowed. Perhaps similar classes should end up in the BCL, or a more user-friendly way of performing a deep-copy should be provided...

re: ExecutionContext vs SynchronizationContext

Stephen Toub - MSFT — Sun, 25 Nov 2012 18:43:42 GMT

@kyann: There's no way today to modify the ExecutionContext.Capture logic. However, you can store / retrieve data that flows with the captured context by using CallContext.LogicalSetData / CallContext.LogicalGetData.

re: ExecutionContext vs SynchronizationContext

kyann — Sun, 25 Nov 2012 17:06:52 GMT

Hi,

Is it possible to "extend" the Capture to add some more info to be restored ?

re: ExecutionContext vs SynchronizationContext

arnshea — Fri, 22 Jun 2012 17:41:13 GMT

Ahh, that explains it. SynchronizationContext.Current doesn't flow across await points but is captured, the way local variables passed to a lambda are captured, at the moment the continuation is registered.

Thanks!

re: ExecutionContext vs SynchronizationContext

Stephen Toub - MSFT — Thu, 21 Jun 2012 15:41:27 GMT

Hi Shea-

The marshaling back to the UI thread is handled by the awaiter. The example is awaiting a Task from the UI thread, so when the Task completes, the awaiter Posts back to the SynchronizationContext that was current when the await was issued.

re: ExecutionContext vs SynchronizationContext

arnshea — Wed, 20 Jun 2012 05:45:38 GMT

There's an example on msdn analogous to the following:

myObject_Click(...)

{

await DoStuffAndUpdateUI();

}

where DoStuffAndUpdateUI() in turn does an await (for a webrequest download) then *updates the UI* without explicitly marshaling back to the UI thread. However, the UI update is marshaled back onto the UI thread.

Does this mean that, at least in the case of WinForms, that SynchronizationContext is flowing across awaits? e.g., it's using the public ExecutionContext.Capture() ?

The msdn example is at msdn.microsoft.com/.../hh300224(v=vs.110)

Great post!

re: ExecutionContext vs SynchronizationContext

Stephen Toub - MSFT — Sun, 17 Jun 2012 21:19:31 GMT

Nadav, as you've observed, CurrentCulture is not flowed as part of ExecutionContext.

re: ExecutionContext vs SynchronizationContext

Nadav — Sun, 17 Jun 2012 06:56:31 GMT

Does CurrentCulture get captured in the ExecutionCintext?

From what I've seen in dot 4.0 it does not...

re: ExecutionContext vs SynchronizationContext

tobi — Sat, 16 Jun 2012 12:15:15 GMT

This makes me think if a [CallContextStatic] attribute would be useful in analogy to the existing [ThreadStatic] attribute.

Or maybe it is better to encourage "empty" ExecutionContexts so the capturing and restoring operations are fast in the common case.

re: ExecutionContext vs SynchronizationContext

svick — Fri, 15 Jun 2012 21:19:43 GMT

Yeah, it was interesting. Thanks for writing this article.