Locking in ProviderGraph to prevent duplicate code generation #3109
Conversation
felixkmh
commented
Apr 2, 2024
•
felixkmh
commented
- Implemented fix as discussed in Duplicate Type Generation #3083
- Added single lock object to synchronize code generation
- Added unit test to cover this fix
- Confirm that the project builds
- All automated tests succeed
felixkmh
changed the title
| @@ -23,7 +24,10 @@ public ProviderGraph(StoreOptions options) | |||
|
|
|||
| public void Append<T>(DocumentProvider<T> provider) where T : notnull | |||
| { | |||
| _storage = _storage.AddOrUpdate(typeof(T), provider); | |||
| lock (_storageLock) | |||
There was a problem hiding this comment.
Don't do the lock here, it's unnecessary w/ the immutable hash map
There was a problem hiding this comment.
I'm not sure how ImHashMaps work exactly, but the reason I also locked it is because I thought that if two threads enter this method concurrently, then they call AddOrUpdate on the same instance. Then they each would create a new map based on that same map instance, resulting in two separate instances that do not contain the item the other thread tried to add. The assignment only happens after AddOrUpdate returns, so whoever assigns to _storage last "wins".
There was a problem hiding this comment.
Maybe I'll just add that as another test case and see if that can happen. Although tests of that nature aren't the most reliable.
There was a problem hiding this comment.
Seems that it is at least possible:
I can't speak to how likely that is in practice, but I'd argue that the impact of keeping the lock would be negligible.
|
@felixkmh Thanks for taking this on! |
