-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Fixed deadlock in System.Resources.ResourceSet #75
Conversation
21e6070 to
59393c0
Compare
|
I updated the commit message to match contribution guidelines |
|
Thanks for the contribution. At first glance the change look ok. However, since this code is shared with Desktop we need to run this through additional validation to make sure we don't break anything. Once we are sure we are not breaking anything we are going to merge it in. @ramarag can you take a look at this? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you fix the indentation here. I am almost done running the tests. will merge when I get the updated PR
Also please do squash your commits to a single one
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ramarag, sorry for broken indentation, just tried to keep number of lines changed at minimum.
ResourceSet internal enumerator uses the following lock order:
1. lock _resCache (as _reader._resCache)
in System.Resources.ResourceSet+ResourceEnumerator.Entry
2. lock reader (this)
in the body on of _reader.AllocateStringForNameIndex
RuntimeResourceSet.GetObject uses the following lock order:
1. Lock on reader
2. Lock on _resCache
(on the same instance as passed to the reader ctor)
That causes deadlock when one thread tries to enumerate the ResourceSet
while another thread reads a specific object from the same set.
Added lock in System.Resources.ResourceSet+ResourceEnumerator.Entry,
so both code paths locks on reader first.
Fix Connect Issue ID #580259
59393c0 to
eedb57d
Compare
|
I added an indentation and rebased commit to master. Please review. |
|
LGTM... @jkotas can you take a look too. |
|
LGTM |
Fixed deadlock in System.Resources.ResourceSet
|
Thank you for getting this fixed! |
Fixed deadlock between ResourceSet iterator and and ResourceSet.GetObject.
Using both ResourceSet iterator and ResourceSet.GetObject is a common scenario in web app - resource set is used for server view rendering (through ResourceSet.GetObject) and in the time that resource set is offloaded to client side as JSON (through ResourceSet iterator). There is a high probability that app will deadlock on start in that case.
Connect Issue: #580259 - closed as non-reproducable. I have no access to the source code in that connect issue, but deadlock graph seems to be exactly the same as in my sample app.
Sample app to reproduce the issue: https://github.com/PashaPash/ResManDeadlock
Details from Stack Exchange thread:
The problem is that when using a ResourceSet the iterator takes out locks on the internal resource cache of the ResourceReader http://referencesource.microsoft.com/#mscorlib/system/resources/resourcereader.cs,1389 and then in the method AllocateStringNameForIndex takes out a lock on the reader itself: http://referencesource.microsoft.com/#mscorlib/system/resources/resourcereader.cs,447
Getting an object takes out the same locks int the opposite order:
http://referencesource.microsoft.com/#mscorlib/system/resources/runtimeresourceset.cs,300
and http://referencesource.microsoft.com/#mscorlib/system/resources/runtimeresourceset.cs,335