Skip to content

Remove rust_atomic_increment/decrement and rust_compare_and_swap_ptr #3527

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

Closed
brson opened this issue Sep 18, 2012 · 4 comments
Closed

Remove rust_atomic_increment/decrement and rust_compare_and_swap_ptr #3527

brson opened this issue Sep 18, 2012 · 4 comments
Labels
A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows C-cleanup Category: PRs that clean code up or issues documenting cleanup. E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.
Milestone

Comments

@brson
Copy link
Contributor

brson commented Sep 18, 2012

There are intrinsics for this purpose now.

@vertexclique
Copy link
Member

How to remove usage of rust_atomic_increment in src/libcore/private.rs line 455 ?

let new_count = rustrt::rust_atomic_increment(&mut ptr.count);

@brson
Copy link
Contributor Author

brson commented Oct 15, 2012

Here's the list of intrinsics: https://github.com/mozilla/rust/blob/incoming/src/rustc/middle/trans/foreign.rs#L800

And here are the ones used by core::pipes: https://github.com/mozilla/rust/blob/incoming/src/libcore/pipes.rs#L240

rust_atomic_increment needs to be replaced either with atomic_xadd, atomic_xadd_acq or atomic_xadd_rel. Probably atomic_xadd is the safest unless you can determine that one of the other two is appropriate. I'm not familiar with the differences.

@brson
Copy link
Contributor Author

brson commented Oct 15, 2012

@bblum will know for sure

@bblum
Copy link
Contributor

bblum commented Oct 15, 2012

atomic_xadd_acq would be plenty safe in the clone_shared_mutable_state case.

The suffixes denote whether the instruction is intended to have "acquire" or "release" semantics, which means that on the processor (or maybe compiler instruction-selection?) level, they might be reordered to be earlier (for acquire) or later (for release). Using atomic_xadd is always safer than ..._acq or ..._rel, which are only for potential performance.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows C-cleanup Category: PRs that clean code up or issues documenting cleanup. E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.
Projects
None yet
Development

No branches or pull requests

4 participants