Skip to content
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

channels: fix memory ordering violation in iterate #52407

Merged
merged 1 commit into from
Dec 6, 2023

Conversation

vtjnash
Copy link
Sponsor Member

@vtjnash vtjnash commented Dec 5, 2023

Channel iterate calls might miss trailing items without this patch. I have not seen proof of this reaching a failure, but we do appear to be missing this ordering specification in visual review.

Should not make a difference to generated code on x86, which already has TSO guaranteed, but may alter optimizations and other CPUs with weaker memory orderings.

Channel `iterate` calls might miss trailing items without this patch. I
have not seen proof of this reaching a failure, but we do appear to be
missing this ordering specification in visual review.

Should not make a difference to generated code on x86, which already has
TSO guaranteed, but may alter optimizations and other CPUs with weaker
memory orderings.
@vtjnash vtjnash added backport 1.9 Change should be backported to release-1.9 backport 1.10 Change should be backported to the 1.10 release domain:multithreading Base.Threads and related functionality labels Dec 5, 2023
@oscardssmith oscardssmith added the kind:bugfix This change fixes an existing bug label Dec 5, 2023
@vchuravy vchuravy merged commit 856e112 into master Dec 6, 2023
9 of 11 checks passed
@vchuravy vchuravy deleted the jn/channel-iterate-ordering branch December 6, 2023 15:35
KristofferC pushed a commit that referenced this pull request Dec 12, 2023
Channel `iterate` calls might miss trailing items without this patch. I
have not seen proof of this reaching a failure, but we do appear to be
missing this ordering specification in visual review.

Should not make a difference to generated code on x86, which already has
TSO guaranteed, but may alter optimizations and other CPUs with weaker
memory orderings.

(cherry picked from commit 856e112)
@KristofferC KristofferC mentioned this pull request Dec 12, 2023
17 tasks
KristofferC added a commit that referenced this pull request Dec 17, 2023
Backported PRs:
- [x] #51234 <!-- Fix getfield codegen for tuple inputs and unknown
symbol fields. -->
- [x] #52170 <!-- fix invalidations related to `ismutable` -->
- [x] #52342 <!-- Add single-term multiplication for `AbstractQ` on
v1.10 and above -->
- [x] #52333 <!-- bugfix for dot of Hermitian{noncommutative} -->
- [x] #52407 <!-- channels: fix memory ordering violation in iterate -->
- [x] #52405 <!-- Bump LLVM to 15.0.7+10 to fix GC issue -->
- [x] #52441 <!-- Remove `Pkg` dependency from `SuiteSparse_jll` -->
- [x] #52367 <!-- docs: add notes about scratchspaces in depot -->
- [x] #52456 <!-- Make `jl_write_coverage_data` dllexported again -->
- [x] #52294 <!-- GC scheduler refinements -->
- [x] #52359 <!-- make custom log macros work -->
- [x] #52548
@KristofferC KristofferC removed the backport 1.10 Change should be backported to the 1.10 release label Dec 17, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport 1.9 Change should be backported to release-1.9 domain:multithreading Base.Threads and related functionality kind:bugfix This change fixes an existing bug
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants