Fix incorrect verification at boundary #2485
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
At end of loop there is a possible sequence
which can result myValue equal to hisRealValue
but it is still a legal sequence.
Added check to handle missed sequence.
The issue actually shows up when the two threads reading each other's values reach 499999, and now at the last iteration, one thread completes its operations and exits the loop. Now the next thread starts its operations, completes the do-while block, and will exit the loop. Below is dry run of the sequence for the both threads
After the above execution sequence, below are the values we see while verifying the thread 1 buffers
Since myValue is equal to myValReadByHim, we are resulting in an error that says
the fence is not working and both threads read a stale value. That is correct, but not at the boundary condition; here we haven't read any stale value, and the fence is working correctly. The only problem is thread 2 forced out of the loop because myValue is not less than 500000; if it's not at the boundary, it would have taken one more iteration, and the values after this iteration would not have hit this condition.This fix makes the condition more robust. If both threads read stale values, they would read the same old values, so checking whether
hisValue == myValReadByHimwill make sure both threads read the stale value even at the boundaries. Now with both conditions we can be sure that both threads have read stale values.