Comments (7)
I would find it sufficient for this crate to state that enabling the atomic_polyfill
feature when depending on spin
in a library crate is very dangerous and should not be done. You can trigger cargo to merge the feature together for an underlying library crate by including spin
in the toplevel crate with the atomic_polyfill
feature.
Detecting the target to be multicore in Rust code is also impossible when you have heterogeneous cores that depend on cargo-microamp
to be built.
Making Mutex
/ RwLock
generic over the type of atomics seems unnecessarily complex to me. It would require all depending crates to expose it in their public API, always. This still requires crate authors to be disciplined in this regard.
from spin-rs.
Perhaps there is another, more sound solution, created by @taiki-e:
https://crates.io/crates/portable-atomic
This crate includes the following cfg flag:
--cfg portable_atomic_unsafe_assume_single_core
Assume that the target is single-core. When this cfg is enabled, this crate provides atomic CAS for targets where atomic CAS is not available in the standard library.
This ensures that only the last link in the dependency chain has control and unintentional activation should be impossible.
from spin-rs.
While I theoretically want to implement this (I've worked with Rust on the GBA in the past) I'm a little worried about the possible soundness implications. From the atomic-polyfill
README:
Note: polyfill is based on critical sections using the critical-section crate. The default implementation is based on disabling all interrupts, so it's unsound on multi-core targets. It is possible to supply a custom critical section implementation, check the critical-section docs for details.
This seems to imply that enabling such a feature on a multi-core platform might accidentally result in spin
becoming unsound. I'd ordinarily be fine with this: it's something the crate user opts into, so it's their fault if they don't check the target.
Except when they don't opt into it. Cargo's dependency resolver unifies feature sets, and this may lead to a sub-dependency accidentally relying on unsound behaviour because a crate higher up in the dependency tree enables the feature.
I don't really see a way out of this, cargo's feature system just isn't designed to deal with these sort of cases, and I'm not aware of a way to force the resolver not to unify when a specific feature flag is enabled.
from spin-rs.
What do you suggest? I've been told atomic-polyfill
is the go-to for implementing atomics by means of disabling interrupts on single-threaded systems, but there's no crate I can find which builds on top of it to provide Mutex
and RwLock
APIs.
from spin-rs.
One option might be to make Mutex
/RwLock
generic over the type of the lock integer, which would allow swapping between real atomic locking and polyfill locking with something like this:
#[cfg(feature = "building_for_the_gba")]
type Mutex<T> = spin::Mutex<T, DisableIrq>;
#[cfg(not(feature = "building_for_the_gba"))]
type Mutex<T> = spin::Mutex<T, Atomic>;
Obviously, this won't work if you're depending on something that requires spin
(like lazy-static
).
from spin-rs.
This is a good idea and seems like it would resolve my concerns! @Wassasin: if this was a route you wanted to go down, I'd be happy to accept the PR.
from spin-rs.
This has now been implemented by #120, thanks to @fralalonde !
from spin-rs.
Related Issues (20)
- Inconsistent feature name HOT 2
- `lock_api` feature is not available in version 0.7.1 and 0.8.0. HOT 4
- Cannot borrow `lazy::Lazy<T>` mutably? HOT 5
- Remove `panicked` field from Once's Finish guard HOT 2
- Implement Once::get_mut_unchecked and Once::into_inner_unchecked HOT 4
- unwrap function in MutexGuard? HOT 4
- `Once::call_once` doesn't guarantee that the given closure is called only if this is the first time `call_once` has been called. HOT 2
- RwLock::try_read is unsound HOT 2
- MIRI build in CI is failing HOT 4
- portable_atomic feature does not compile HOT 2
- CI: Set minimal permissions on GitHub Workflow HOT 3
- Why was spin 0.9.6 yanked? HOT 2
- Unsoundness in `Once::try_call_once()`
- Are `rwlock` and `spin_mutex` compatible with `portable_atomic`? HOT 11
- `Lazy` panics under bare metal environment HOT 10
- Add a Security-Policy
- Add `std` feature with support for thread yielding HOT 1
- Switching to GitHub actions HOT 1
- Need a spinlock that never uses std::thread::yield_now HOT 9
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from spin-rs.