Resolving a SingleInstance registration locks during subsequent resolves, even if the instance has already been created.

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Register the first type as a SingleInstance.
2. Resolve the first type.
3. Register a second type that, during activation, resolves the first type on 
another thread.
4. Resolve the second type.

What is the expected output? What do you see instead?
I expect that the second type will resolve successfully because it depends on a 
single instance that has already been resolved. What I see is the process 
deadlocking because the other thread can't acquire the necessary lock to 
resolve the already-constructed first type.

What version of Autofac are you using? On what version of .NET/Silverlight?
3.0.1, .NET 4.0

Please provide any additional information below.
We noticed this issue during migration from Unity to Autofac. The attached 
LifetimeScope.cs.patch is what we're currently using as the workaround. The 
attached LockTests.cs tests the scenario that we encountered, and what is 
described in the steps to reproduce. In our application scenario, the "other 
thread" is essentially a database I/O queue.

Original issue reported on code.google.com by james_h...@lecotc.com on 8 Mar 2013 at 9:14

Attachments:

• LifetimeScope.cs.patch
• LockTests.cs

[GoogleCodeExporter]

Original comment by travis.illig on 9 Mar 2013 at 1:26

• Added labels: Module-Core

[GoogleCodeExporter]

Original comment by alex.meyergleaves on 11 Mar 2013 at 3:28

• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Hi all,

I think the lock in LifetimeScope.ResolveComponent() can be safely removed. Am 
I wrong?

Original comment by nikitin....@gmail.com on 16 Mar 2013 at 10:38

Attachments:

• LifetimeScope.cs.patch

[GoogleCodeExporter]

This issue was closed by revision 7fb6d181186e.

Original comment by alex.meyergleaves on 12 Apr 2013 at 12:38

• Changed state: Fixed