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

Safe version of UnsafeArc that accepts only atomic types #10112

Closed
bblum opened this issue Oct 28, 2013 · 10 comments
Closed

Safe version of UnsafeArc that accepts only atomic types #10112

bblum opened this issue Oct 28, 2013 · 10 comments
Labels
A-attributes Area: Attributes (`#[…]`, `#![…]`) A-concurrency Area: Concurrency A-typesystem Area: The type system C-enhancement Category: An issue proposing an enhancement or a PR with one.

Comments

@bblum
Copy link
Contributor

bblum commented Oct 28, 2013

To share data such as counters cross-task, you either have to use the performance-impacting RWArc or litter your code with unsafe using an UnsafeArc. If all you want to be doing cross-task is atomically incrementing counters or shuffling AtomicOptions around, it would be safe to avoid the RWArc's overhead.

To do generally, this would require a new Atomic kind, which would be introduced with unsafe attributes in the atomics library and could be derived by other aggregate types that contained only atomics (but NOT enums).

@bblum
Copy link
Contributor Author

bblum commented Oct 28, 2013

this is a low-priority post-1.0-compatible enhancement

@alexcrichton
Copy link
Member

Closing, this is handled with Arc plus Share types. You can safely mutate Arc<AtomicUint> now that we've decided to make mutators use &self instead of &mut self

@bblum
Copy link
Contributor Author

bblum commented Apr 18, 2014

is that safe with AtomicPtr too?

@alexcrichton
Copy link
Member

It is indeed, all of the atomics have changed to taking &self rather than &mut self

@bblum
Copy link
Contributor Author

bblum commented Apr 18, 2014

I mean... didn't AtomicPtr used to have a get(&'a self) -> &'a T function? If that's still around it seems like you could use two simultaneous &self pointers to mutate the pointer while a pointer to the inside was already in scope.

@alexcrichton
Copy link
Member

There's no longer any way to borrow an AtomicXXX (for that reason), I think AtomicPtr has changed over time (now it's Atomic<*mut T>)

@bblum
Copy link
Contributor Author

bblum commented Apr 18, 2014

huh, so if you want to put a ~T inside, how do you manage when it gets freed?

@alexcrichton
Copy link
Member

The AtomicPtr type doesn't manage an allocation (it only deals with *mut T), so there's no need for a destructor. The one you're thinking of may have evolved into AtomicOption<T> which is essentially Atomic<Option<~T>> which has its own destructor to deallocate the ~T if there's one inside on drop.

@bblum
Copy link
Contributor Author

bblum commented Apr 18, 2014

Oh yeah, that's the one I meant. So there's no AtomicOption::get(&'a self) - > &'a T anymore?

@alexcrichton
Copy link
Member

It is indeed gone: http://static.rust-lang.org/doc/master/std/sync/atomics/struct.AtomicOption.html

Only atomic operations are exposed (getting/setting/taking/etc)

flip1995 pushed a commit to flip1995/rust that referenced this issue Jan 12, 2023
[arithmetic-side-effects] Consider negative numbers and add more tests

Same as rust-lang#9867.

Opening again because it is not possible to randomly choose a reviewer in an ongoing PR like in the rust repo.

---

changelog: PF: [`arithmetic_side_effects`]: No longer lints on corner cases with negative number literals
[rust-lang#9867](rust-lang/rust-clippy#9867)
<!-- changelog_checked -->
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-attributes Area: Attributes (`#[…]`, `#![…]`) A-concurrency Area: Concurrency A-typesystem Area: The type system C-enhancement Category: An issue proposing an enhancement or a PR with one.
Projects
None yet
Development

No branches or pull requests

2 participants