-
Notifications
You must be signed in to change notification settings - Fork 795
[SYCL][E2E] Avoid illegal failure order in compare_exchange_strong test #19513
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
Open
robertszafa
wants to merge
1
commit into
intel:sycl
Choose a base branch
from
robertszafa:atomic_cmp_xchg_test
base: sycl
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
+24
−3
Open
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
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.
Why don't we just assert that
failure_order
is allowed and then modify the callers? Is that because we use the same parameter to test multiple functions and other functions can accept that?If so, I think we should use the strictest memory order and not the weakest instead of the unsupported, because theoretically the caller might be checking for side effects that weaker one can't guarantee.
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.
I've chosen
memory_order::relaxed
as the fallback forfailure_order
, because that is what is used for the default memory order fallback forAtomicRef
in this test. I can change this toacquire
-- I don't think anything stronger is required since there are no side effects to release on failure.Another possibility, and my preferred route, is changing the
sycl::AtomicRef::compare_exchange_strong()
function to change illegal failure memory orders to the next best legal ones: useacquire
instead ofacq_rel
andrelaxed
instead ofrelease
. This would match the behaviour of the C++ std library: https://en.cppreference.com/w/cpp/atomic/atomic_ref/compare_exchangeRe modifying the test callers. The
compare_exchange_test_orders_scopes
template function generates all the memory orders to test. This order template parameter is ultimately used for bothsuccess_order
andfailure_order
incompare_exchange_strong
. If we prevent calls withacq_rel
andrelease
being used fororder
incompare_exchange_test_orders_scopes
, thensuccess_order
will also not be tested with these variants. If we care about all combinations ofsuccess_order
andfailure_order
being tested, then we could add another template function that generates all allowed failure orders, in addition to all possible success orders and memory scopes. However, I don't think the E2E are expected to test every possible parameter combination.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.
+ @gmlueck for
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.
Delegating to @Pennycook
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.
Good catch. This is definitely a specification bug: we say it's equivalent to
compare_exchange_strong(expected, desired, order, order, scope)
, but that would be UB in several cases. I'll open a pull request against the SYCL specification to fix this.FWIW, here's the equivalent wording in the ISO C++ specification, which is what I'll try to align with:
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.
New wording proposed in KhronosGroup/SYCL-Docs#891.
Uh oh!
There was an error while loading. Please reload this page.
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.
Great, it'd be nice to have this be clear in the SYCL spec.
Do you want me to open a new PR that implements this in
atomic_ref_base::compare_exchange_strong(expected, desired, order, order, scope)
? This would mean that the change from this PR to the compare_exchange_strong E2E test is not needed.All the compare_exchange variants call into
atomic_ref_base::compare_exchange_strong(expected, desired, order, order, scope)
, so adding something like the below there should be enough: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.
Yes, please do.
We might want to hold off on merging it until KhronosGroup/SYCL-Docs#891 is merged, just to be on the safe side. But given that this is already the behavior of ISO C++, the chances of it being accepted as a bug fix are very high.