Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deadlock - DefaultNamingSubsystem.GetHandlers() vs DefaultGenericHandler.type2SubHandler #34

Closed
anton-iermolenko opened this issue Nov 15, 2013 · 1 comment

Comments

@anton-iermolenko
Copy link
Contributor

We have found a deadlock with 2 threads trying to resolve 2 components (c1 and c2) implementing 2 separate generic interfaces, but then component c1 has a dependency which is in turn dependent on component c2.

In terms of code it happens because of following:
Imagine thread t1 accessing DefaultNamingSubsystem.GetHandlers() via DefaultGenericHandler.GetSubHandler (this locks type2SubHandler in that class). Another thread t2, accesses the same DefaultNamingSubsystem.GetHandlers() from Resolve(), acquires upgradable lock, and then in GetHandlersNoLock routine calls Supports(service) on the same DefaultGenericHandler (this will require access to type2SubHandler which is already held by thread t1). Thread t1 in the mean time awaits upgradable read lock from thread t2. Deadlock

This issue was found in 3.2 and confirmed in latest 3.2.1 (which means fix to IOC-370 didn't resolve this specific case).

anton-iermolenko added a commit to anton-iermolenko/Windsor that referenced this issue Nov 15, 2013
…lers() vs DefaultGenericHandler.type2SubHandler)
anton-iermolenko added a commit to anton-iermolenko/Windsor that referenced this issue Nov 15, 2013
…lers() vs DefaultGenericHandler.type2SubHandler)
@anton-iermolenko
Copy link
Contributor Author

Sent in a pull request which resolves this issue and related ones. Also, it has a unit test which allows reproducing it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant