-
Notifications
You must be signed in to change notification settings - Fork 323
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
Fix timing issue in parallel execution #4629
Conversation
/azp run |
No commit pushedDate could be found for PR 4629 in repo microsoft/vstest |
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
// This must be set last, every loop below looks at this property, | ||
// and they can do so from a different thread. So if we mark it as HasWork before actually assigning the work | ||
// we can pick up the slot, but it has no associated work yet. | ||
slot.HasWork = true; |
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 fix.
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.
Linking #4630 here to explain why we approve the change as-is.
Co-authored-by: Amaury Levé <[email protected]> Fix timing issue in parallel execution (#4629)
Description
Parallel workers are able to pick up work between setting HasWork and actually associating the workload, which leads to the work being unscheduled. The test run (or test discovery) then never finishes. This was observed on a run with 99 dlls, and can be reproduced locally. To me it was on parallel runs of 12 hosts.
This fix moves HasWork to be the last item to be set under the lock, so the readers that are outside of the lock cannot read it too early before the slot is completely populated.