In Disposer.cs L80 (this one normally completes synchronously hence it has no impact) and L90 (this one impacts the situation below) you are using .ConfigureAwait(false) which runs the continuations on the thread pool and not on the SynchronizationContext.

This leads to the behavior, that all subsequent Dispose and DisposeAsync calls after the first DisposeAsync (which runs on the SynchronizationContext) run on worker threads and not on the thread which called Container.DisposeAsync.

In the synchronous case, Container.Dispose will call all Dispose methods on the same thread where it was invoked.

The unexpected thread change during disposal leads to the problem that thread-sensitive Dispose methods (e.g. accessing UI elements running on a UI thread) get into trouble and must take care of threading by their own.

I could not figure out from the docs what the intended threading model is and what to expect/assume, when calling Container.DisposeAsync.

Getting rid of .ConfigureAwait(false) in L80 and L90 would ensure that each Dispose and DisposeAsync call runs on the respective SynchronizationContext on which Container.DisposeAsync is called.

Is this the intended behavior by AutoFac? If so, why is the .ConfigureAwait(false) necessary? If it is necessary, how can I deal with these 'thread-changing' situation during dispose.

Thanks for any insights for this issue.

In Disposer.cs L80 (this one normally completes synchronously hence it has no impact) and L90 (this one impacts the situation below) you are using .ConfigureAwait(false) which runs the continuations on the thread pool and not on the SynchronizationContext.

This leads to the behavior, that all subsequent Dispose and DisposeAsync calls after the first DisposeAsync (which runs on the SynchronizationContext) run on worker threads and not on the thread which called Container.DisposeAsync.

In the synchronous case, Container.Dispose will call all Dispose methods on the same thread where it was invoked.

The unexpected thread change during disposal leads to the problem that thread-sensitive Dispose methods (e.g. accessing UI elements running on a UI thread) get into trouble and must take care of threading by their own.

I could not figure out from the docs what the intended threading model is and what to expect/assume, when calling Container.DisposeAsync.

Getting rid of .ConfigureAwait(false) in L80 and L90 would ensure that each Dispose and DisposeAsync call runs on the respective SynchronizationContext on which Container.DisposeAsync is called.

Is this the intended behavior by AutoFac? If so, why is the .ConfigureAwait(false) necessary? If it is necessary, how can I deal with these 'thread-changing' situation during dispose.

Thanks for any insights for this issue.

• multithreading
• autofac
• dispose

Share Improve this question Follow asked Mar 13 at 12:53 Bernd StoetzelBernd Stoetzel 111 bronze badge

Add a comment  | 

1 Answer 1

Sorted by: Reset to default 0

Looking at the Microsoft.Extensions.DependencyInjection disposal mechanism, it appears they, too, do ConfigureAwait(false) for async disposables not using ValueTask. That's admittedly a miss in Autofac, but it's consistent.

While I think Autofac could improve with some support for ValueTask, the consistent behavior here is valuable to ensure folks switching from one container to another won't be surprised.

We'd be happy to take a PR to make Autofac ValueTask and async disposable handling even closer to the Microsoft container, but to ensure consistent behavior, we likely won't switch how ConfigureAwait works.