Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Thread safety of context item collections #1043
We have code that calls .First() on a collection in a Microsoft.Dynamics.CRM.System context that is deadlocked because of the lack of thread-safety of the Dictionary<> class. A process dump shows that multiple threads are in the EntityTracker.InternalAttachEntityDescriptor() method, calling the .Add()/.Insert() method of the 'identityToDescriptor' Dictionary<>.
The calling code looks like:
It appears that the fix would be to change each Dictionary<> to a ConcurrentDictionary<> for the EntityTracker internal members: 'entityDescriptors', 'identityToDescriptor', and 'bindings'.
If there is some other work-around, please let me know. Thanks.
The call stack looks like:
The version of the Microsoft.OData.* assemblies that are being used is 22.214.171.124, however, looking at the current code in the git repository, it appears that ultimately the same functions will be called, resulting in an .Add()/.Insert() on a thread-unsafe Dictionary<>.
@chrisbigart, thanks for filing the issue. Can you please open a pull request to this one with your proposed fix?
#905 and #990 serve as two references that you can follow. If we use ConcurrentDictionary, we have to make sure that we have the
So, I watched the other versions of these issues, and here are my concerns with ConcurrentDictionary:
referenced this issue
Jan 29, 2018
@robertmclaws, good questions.
We also asked that question to ourselves and we decided that as long as we still have tests running against it (to re-cap: our most recent statement was indeed that we're not supporting Windows Phone 8.0), we would still like to have our all of the tests buildable and passing. It would make sense for us to remove those WinPhone8.0 tests as well, but we currently don't have resources allocated to going through and cleaning up all WinPhone related items at the moment. Having said all that, it's less costly and risky at the moment to add another WINDOWSPHONE preprocessor.
I'm not sure what decisions were made regarding the choice of the ConcurrentDictionary version or why we have a non-concurrent version for the portable. I'll ask around, but we should test the portable version of ConcurrentDictionary since it exists.