Deadlock in ServiceLocator

[PatrickKursawe]

Deadlock in ServiceLocator

[GeertvanHorrik]

Thanks for reporting. Is there a way you can provide this in a (failing) unit test format? Then we can try to embed the tests into catel and fix if possible.

[PatrickKursawe]

Will try to cook something up when I am done with removing that default constructor.

[PatrickKursawe]

Unfortunately, I can't reproduce the issue in a simplified test case, so maybe close this issue?

Looking at the catel source, though, something seems a little odd to me:

In ServiceLocatorExtensions.TryResolveType, the "this" (the service locator itself) is used as a lock object.
In ServiceLocator.IsTypeRegisteredInCurrentLocator, the dedicated internal lock object is used as a lock.
How can this result in a deadlock? Do you understand what is happening here?

What's the reason for locking in the extension method at all? That lock should not prevent anyone from removing the type between the check for registration and the attempt at object creation, as that method is using a different lock.
But this lock will result in a deadlock if some object that is created while resolving calls TryResolveType from a different thread in the constructor (for example because of GUI depending code). So, if you don't mind that I am wasting your time more than I already did, what scenario is the lock in the extension method supposed to avoid?
Thanks!

[GeertvanHorrik]

Great find about the lock in the service locator. I've removed the lock (it's not needed). We also worked on a fix that was caused by the ConfigurationService (took us a while to figure out). We will release a new alpha with the fixes soon.