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

Use AtomicCell<u64> on targets with target_has_atomic less than 64 #286

Closed
wants to merge 3 commits into from

Conversation

taiki-e
Copy link
Contributor

@taiki-e taiki-e commented Oct 7, 2019

Closes #141

cc #48

Related: tokio-rs/tokio#1538

.github/workflows/ci.yml Outdated Show resolved Hide resolved
// `#[cfg(target_has_atomic = "64")]`.
// Refs: https://github.com/rust-lang/rust/tree/master/src/librustc_target
cfg_if::cfg_if! {
if #[cfg(not(any(target_arch = "arm", target_arch = "mips", target_arch = "powerpc")))] {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Many target_arch = "arm" targets are target_has_atomic = "64", but only some targets seems different.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

cc #48 Should we support these targets?

Copy link
Collaborator

Choose a reason for hiding this comment

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

I would definitely support arm-linux-androideabi, I'm hard pressed to find a deployment target with armv5 that is relevant for async-std.

@taiki-e
Copy link
Contributor Author

taiki-e commented Oct 7, 2019

CI failure seems due to the fact that I enabled the test.

@ghost
Copy link

ghost commented Oct 17, 2019

This PR needs another rebase.

@taiki-e taiki-e force-pushed the atomic branch 2 times, most recently from bbd761b to 83487da Compare October 18, 2019 05:00
@taiki-e taiki-e mentioned this pull request Oct 18, 2019
@taiki-e taiki-e force-pushed the atomic branch 2 times, most recently from 83487da to d6c5377 Compare October 18, 2019 08:55
@taiki-e
Copy link
Contributor Author

taiki-e commented Oct 18, 2019

This PR should not have changed the behavior on macOS, but this test failed on macOS on CI... But I couldn't reproduce this locally.

@nbdd0121
Copy link
Contributor

Would it be better to name it as something else rather than AtomicU64? Rust atomics are guaranteed to be layout-wise identical to their corresponding integer type, so naming it as AtomicU64 may incorrectly represent that.

Also: std::sync::Mutex is too heavy to protect just an integer. It'd be better to have a spinlock instead.

@taiki-e
Copy link
Contributor Author

taiki-e commented Oct 20, 2019

Would it be better to name it as something else rather than AtomicU64? Rust atomics are guaranteed to be layout-wise identical to their corresponding integer type, so naming it as AtomicU64 may incorrectly represent that.

I don't intend to make these implementations public, so I don't think it's a problem. However, if #355 is merged, we may need to consider this.

Also: std::sync::Mutex is too heavy to protect just an integer. It'd be better to have a spinlock instead.

I agree. And another advantage of this is AtomicU64::new can be const function.

@nbdd0121
Copy link
Contributor

Another thought, would it make sense to do similar thing as crossbeam's AtomicCell which uses a global Mutex instead? This can guarantee layout compatibility with u64, as well as a const new fn.

Copy link

@ghost ghost left a comment

Choose a reason for hiding this comment

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

oops, wanted to click "request changes"

@taiki-e
Copy link
Contributor Author

taiki-e commented Nov 4, 2019

I like the idea of using AtomicCell<u64> from crossbeam-channel as a cross-platform version of AtomicU64 :)

@taiki-e let's do that?

I think it needs a new release of crossbeam-utils including crossbeam-rs/crossbeam#437. So filed crossbeam-rs/crossbeam#444.

@ghost
Copy link

ghost commented Nov 6, 2019

@taiki-e New versions of crossbeam have been published now.

@taiki-e taiki-e changed the title Use our own AtomicU64 on targets with target_has_atomic less than 64 Use AtomicCell<u64> on targets with target_has_atomic less than 64 Nov 7, 2019
@taiki-e taiki-e force-pushed the atomic branch 2 times, most recently from e9abb0c to 745cf87 Compare November 7, 2019 05:51
@taiki-e
Copy link
Contributor Author

taiki-e commented Nov 7, 2019

looks like ci failure is #286 (comment).

@ghost
Copy link

ghost commented Nov 7, 2019

@taiki-e Can you try rebasing/merging with the master branch to see if that helps?

@taiki-e taiki-e force-pushed the atomic branch 2 times, most recently from b48511f to a80d6ae Compare November 8, 2019 04:44
@taiki-e
Copy link
Contributor Author

taiki-e commented Nov 8, 2019

Updated. It seems to succeed on the existing targets (linux,macos,windows), but fails on the newly added targets.

@faulesocke
Copy link

Rebasing this is almost trivial (just remove the Cargo.toml changes). It then applies cleanly and makes async-std work on MIPS and other platforms.

@taiki-e
Copy link
Contributor Author

taiki-e commented Jan 29, 2020

Hmm, still a test mentioned in #286 (comment) is failed on the newly added targets.

@taiki-e taiki-e closed this Mar 21, 2020
@faulesocke
Copy link

Why was this closed? It still does not compile on MIPS.

@flxo
Copy link

flxo commented Mar 26, 2020

I found this PR today while trying to cross compile async-std for arm-linux-androideabi (32bit). There's no u64 atomic support on 32bit arm v7 and thus also the here proposed usage of crossbeam::atomic doesn't solve the problem. The proposal to use AtomicUsize from #451 sounds reasonable to me but it got closed with a reference to here. Maybe someone can elaborate on the state? I'm happy to support on this issue (I would have to brew my own solution/hack anyway...)

@kolapapa
Copy link

kolapapa commented Apr 1, 2020

I found this PR today while trying to cross compile async-std for arm-linux-androideabi (32bit). There's no u64 atomic support on 32bit arm v7 and thus also the here proposed usage of crossbeam::atomic doesn't solve the problem. The proposal to use AtomicUsize from #451 sounds reasonable to me but it got closed with a reference to here. Maybe someone can elaborate on the state? I'm happy to support on this issue (I would have to brew my own solution/hack anyway...)

I thought this PR was going to pass, so I closed it first……

@taiki-e
Copy link
Contributor Author

taiki-e commented Apr 26, 2020

Why was this closed?

Closed because inactive

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request nominated for 1.0 Nominated for 1.0 release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants