Fix new race condition#144
Conversation
|
Not being able to run the entire test suite at the same time is problematic. It is, I suppose, a symptom of the larger problem that is global registrations. Even running So I'm thinking about a mechanism where we take a copy of the configuration in each thread and only update that thread's version on a reset. Make configuration |
|
As I said in my previous comment:
This is solved in the new PR allowing genfu instances. It is likely that threadstatic configurations would not work properly with 'async' operations anyway. |
|
I can see from your log you're still testing PR #133. You should use PR #144, that updates support for the new code added since the original PR was created. (I can see that because the sentence return (Result)_genericPropertyFillersByPropertyType[type] was in line 331, but it should be 334 now, if you check the stack trace.) I have not been able to replicate any error running registrations_can_be_reset. Not with vs nor rider (they seem to have a different behaviour when running tests in parallel). I can confirm the Parallel.For is running at least 10 different threads for that concrete test without interference. |
|
Aside of that, using Reset on the global registration list should interfere other threads, I don't see any wrong in that and fighting against that would be a waste of resources. Operations should be thread safe, meaning that a Reset should not fail in threaded scenarios. Obviously, what you will find in the list if you do that kind of things is non deterministic: you can find your data or some other thread's data. For that reason I think it is much better to use instances, instead a global instance (or static class). That's the reason for PR #146, that allows both use cases. |
This code fixes a new race condition in Filler manager that appeared since #133 was created, regarding generic fillers.
Note that parallel tests and all the other tests should not be executed together. Parallel tests reset registrations interfering other tests.