-
Notifications
You must be signed in to change notification settings - Fork 409
fix: Avoid data races for cacheEntries and index files #556
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
wow , looks good . I will spend some more time to read over this PR 👀 However , it will conflict with #549 ? |
Thanks! No rush at all. But yeah builds off of #549 and the initial work @nerdeveloper did. |
|
I read some of this code , and have a question: what we do is actually make the rough-grain lock (RegenerationLock) to be the fine-grain lock (RepoLock & IndexLock) ? But do we need to keep these rough-grain lock after we did this ? And I see the response time should be reduced literally , and this optimization also related to the #396 . |
good call! I think you are right, I removed the RegenerationLock in 48b75c7 and it looks good. Some quick load test results showed no change but i don't think that lock was necessary anymore! |
|
Looks much more comfortable now , I will review these all changes and make some tests on my mac this weekend . |
scbizu
left a comment
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.
The code here should be really careful for both writing and reviewing XD
|
@jdolitsky hihi , Could you also join the reviewing , I think it is an important fix or refactor PR . |
scbizu
left a comment
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.
LGTM
|
Awesome work there @cbuto |
|
after rebasing with #551, some new data races showed up while running the tests (it seems to be flakey) |
jdolitsky
left a comment
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.
fantastic. thanks for addressing this (apologies for delay in review!)
Signed-off-by: Casey Buto <cbuto@d2iq.com>
Signed-off-by: Casey Buto <cbuto@d2iq.com>
Signed-off-by: Casey Buto <cbuto@d2iq.com>
Signed-off-by: Casey Buto <cbuto@d2iq.com>
Signed-off-by: Casey Buto <cbuto@d2iq.com>
|
latest race fixed in 3946435, I ran the tests quite a few times just to be sure and it looks good! |
Closes #546.
This should resolve the data races seen when running the test suite with the
-raceflag.I took some of the work/feedback from #549 (thanks @nerdeveloper!) and added some additional changes to ensure we are locking when access the index file and cache entries.
I still would like to spend more time on the performance aspect to see if adjusting the locks could help.
Overall this change as is has a slight negative effect on median response time and a extremely positive effect the p95 response time. I assume the p95 response without these changes is fairly high due to data races between requests.
Here are the results from the very small load tests I ran locally.
Here are the test run branches:
Test 8 =
mainTest 9 =
fix/cache-raceTest 10 =
mainTest 11 =
fix/cache-race