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

sync: add sender_weak_count and sender_strong_count for Receiver #6661

Merged
merged 2 commits into from
Jul 2, 2024

Conversation

Rustin170506
Copy link
Contributor

@Rustin170506 Rustin170506 commented Jun 27, 2024

Motivation

close #6653

Solution

Added sender_weak_count and sender_strong_count for Receiver and UnboundedReceiver.

@github-actions github-actions bot added the R-loom-sync Run loom sync tests on this PR label Jun 27, 2024
Copy link
Contributor Author

@Rustin170506 Rustin170506 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔢 Self-check (PR reviewed by myself and ready for feedback.)

}

pub(super) fn weak_count(&self) -> usize {
self.inner.tx_weak_count.load(Relaxed)
Copy link

@randomairborne randomairborne Jun 27, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why Relaxed here? Wouldn't Acquire be appropriate?
(I am curious, not saying you're wrong)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like this is just mirroring the orderings on the equivalent sender methods. I don't think it really matters.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The main difference between them as I understand it is that with tx_weak_count, it's simply a counter. So it doesn't matter what order it's in.
But with tx_count we rely on it to decide whether to close the channel or not, in addition to counting the number, and it's more of a synchronized operation, where we have to make sure that there is a guaranteed ordering of operations on it between threads.
I'm not sure if I'm right about this, I could be completely wrong 😆

@Darksonn Darksonn added A-tokio Area: The main tokio crate M-sync Module: tokio/sync labels Jun 30, 2024
@Rustin170506 Rustin170506 changed the title sync: add weak_count and strong_count for Receiver sync: add sender_weak_count and sender_strong_count for Receiver Jul 1, 2024
Copy link
Contributor

@wathenjiang wathenjiang left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Thanks!

@wathenjiang wathenjiang merged commit fe7285d into tokio-rs:master Jul 2, 2024
77 checks passed
@Rustin170506 Rustin170506 deleted the rustin-patch-Receiver branch July 2, 2024 23:56
This was referenced Jul 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-tokio Area: The main tokio crate M-sync Module: tokio/sync R-loom-sync Run loom sync tests on this PR
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Get mpsc::Sender count on mpsc::Receiver
4 participants