On Sun, Jun 16, 2024 at 03:51:45PM +0100, Gary Guo wrote: > On Fri, 14 Jun 2024 19:39:27 -0700 > Boqun Feng <boqun.feng@xxxxxxxxx> wrote: > > > On Fri, Jun 14, 2024 at 06:28:00PM -0700, John Hubbard wrote: > > > On 6/14/24 6:24 PM, Boqun Feng wrote: > > > > On Fri, Jun 14, 2024 at 06:03:37PM -0700, John Hubbard wrote: > > > > > On 6/14/24 2:59 AM, Miguel Ojeda wrote: > > > > > > On Thu, Jun 13, 2024 at 9:05 PM Boqun Feng <boqun.feng@xxxxxxxxx> wrote: > > > > > > > > > > > > > > Does this make sense? > > > > > > > > > > > > Implementation-wise, if you think it is simpler or more clear/elegant > > > > > > to have the extra lower level layer, then that sounds fine. > > > > > > > > > > > > However, I was mainly talking about what we would eventually expose to > > > > > > users, i.e. do we want to provide `Atomic<T>` to begin with? If yes, > > > > > > then we could make the lower layer private already. > > > > > > > > > > > > We can defer that extra layer/work if needed even if we go for > > > > > > `Atomic<T>`, but it would be nice to understand if we have consensus > > > > > > for an eventual user-facing API, or if someone has any other opinion > > > > > > or concerns on one vs. the other. > > > > > > > > > > Well, here's one: > > > > > > > > > > The reason that we have things like atomic64_read() in the C code is > > > > > because C doesn't have generics. > > > > > > > > > > In Rust, we should simply move directly to Atomic<T>, as there are, > > > > > after all, associated benefits. And it's very easy to see the connection > > > > > > > > What are the associated benefits you are referring to? Rust std doesn't > > > > use Atomic<T>, that somewhat proves that we don't need it. > > > Just the stock things that a generic provides: less duplicated code, > > > > It's still a bit handwavy, sorry. > > > > Admittedly, I haven't looked into too much Rust concurrent code, maybe > > it's even true for C code ;-) So I took a look at the crate that Gary > > mentioned (the one provides generic atomic APIs): > > > > https://crates.io/crates/atomic > > > > there's a "Dependent" tab where you can see the other crates that > > depends on it. With a quick look, I haven't found any Rust concurrent > > project I'm aware of (no crossbeam, no tokio, no futures). On the other > > hand, there is a non-generic based atomic library: > > > > https://crates.io/crates/portable-atomic > > > > which has more projects depend on it, and there are some Rust concurrent > > projects that I'm aware of: futures, async-task etc. Note that people > > can get the non-generic based atomic API from Rust std library, and > > the "portable-atomic" crate is only 2-year old, while "atomic" crate is > > 8-year old. > > > > More interestingly, the same author of "atomic" crate, who is an expert > > in concurrent areas, has another project (there are a lot projects from > > the author, but this is the one I'm mostly aware of) "parking_lot", > > which "provides implementations of Mutex, RwLock, Condvar and Once that > > are smaller, faster and more flexible than those in the Rust standard > > library, as well as a ReentrantMutex type which supports recursive > > locking.", and it doesn't use the "atomic" crate either. > > Note that crossbeam's AtomicCell is also generic, and crossbeam is used > by tons of crates. As Miguel mentioned, I think it's very likely that in > the future we want be able to do atomics on new types (e.g. for > seqlocks perhaps). We probably don't need the non-lock-free fallback of Good, another design bit, thank you! What's our overall idea on sub-word types, like Atomic<u8> and Atomic<u16>, do we plan to say no to them, or they could have a limited APIs? IIUC, some operations on them are relatively sub-optimal on some architectures, supporting the same set of API as i32 and i64 is probably a bad idea. Another thing in my mind is making `Atomic<T>` pub struct Atomic<T: Send + ...> { ... } so that `Atomic<T>` will always be `Sync`, because quite frankly, an atomic type that cannot `Sync` is pointless. Regards, Boqun > crossbeam's AtomicCell, but the lock-free subset with newtype support > is desirable. > > People in general don't use the `atomic` crate because it provides no > additional feature compared to the standard library. But it doesn't > really mean that the standard library's atomic design is good. > > People decided to use AtomicT and NonZeroT instead of Atomic<T> or > NonZero<T> long time ago, but many now thinks the decision was bad. > Introduction of NonZero<T> is a good example of it. NonZeroT are now > all type aliases of NonZero<T>. > > I also don't see any downside in using generics. We can provide type > aliases so people can use `AtomicI32` and `AtomicI64` when they want > their code to be compatible with userspace Rust can still do so. > > `Atomic<i32>` is also just aesthetically better than `AtomicI32` IMO. > When all other types look like `NonZero<i32>`, `Wrapping<i32>`, I don't > think we should have `AtomicI32` just because "it's done this way in > Rust std". Our alloc already deviates a lot from Rust std. > > Best, > Gary
