Skip to content

compiler: Make async handshake flag accesses atomic - #3070

Draft
ggorman wants to merge 1 commit into
fix-wait-timingfrom
fix-async-handshake-atomics
Draft

ggorman wants to merge 1 commit into
fix-wait-timingfrom
fix-async-handshake-atomics

Conversation

@ggorman

@ggorman ggorman commented Oct 16, 2026

Copy link
Copy Markdown
Contributor

Draft on top of #3055 (base fix-wait-timing); to be rebased onto main once #3055 merges.

The handshake lock/flag are plain volatile ints; the separate __atomic_thread_fences order nothing without atomic accesses, so a weakly ordered CPU may see a lock released before the data it guards. Every lock/flag access inside #3055's BusyWait/BusyWaitCall nodes is now an __atomic acquire load or release store (valid C and C++, no declaration change), and ThreadFence is removed.

Tests: test_iet.py::test_async_handshake_atomics[save|prefetch] (fail on #3055 alone); TestStreaming expectations updated. On an H200 node (nvc 25.9) the OpenACC and OpenMP suites give failure sets identical to #3055.

🤖 Generated with Claude Code

The lock and flag an asynchronous task synchronises on are plain volatile ints.
The fences added for them order nothing on their own: a release fence pairs with
an acquire fence only through atomic accesses, so a weakly ordered CPU may e.g.
see a lock released before the data it guards. Access every lock and flag with
__atomic acquire loads and release stores, which are valid in C and C++ and
need no declaration change, and drop the now redundant ThreadFence.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant