为什么对于许多基本类型都存在一种“原子*”类型，而不是通用的“原子<T>”类型？

Question

为什么对于许多基本类型都存在一种“原子*”类型，而不是通用的“原子<T>”类型？

综观该std::sync::atomic模块，可以看到很多不同的Atomic*类型，如AtomicU32，AtomicI16和更多。这是为什么？

锈病泛型和-在我看来-这将是可能增加一个通用的Atomic<T>，其中T由模块中定义的一些特质界（在Java中上下的命名：Atomicable）。该特征将通过可以以原子方式处理的类型来实现，并且用户可以使用Atomic<u32>而不是AtomicU32。

为什么没有通用名称Atomic<T>？为什么会有许多不同的类型呢？

Answer 1

hel*_*low 11

拥有AtomicU8（例如）目的是使用底层硬件来执行原子指令，例如在x86上执行CMPXCHG指令。

原始RFC＃1505建议使用一种Atomic<T>类型。一个主要的关注点是，人们会T以一种意想不到的方式使用，例如Atomic<[u8; 32]>，由于缺乏支持这些功能的硬件，因此无法使用。提出
了使用a的后备/解决方法Mutex，但感觉就像作弊一样，因为编译器对于不同的Ts 会有不同的表现。

最终以RFC＃1543结束，该协议引入了我们今天所知道的Atomic {I，U} {8,16,32,64}类型。

然后在PR＃33048中实现，并在PR＃56753（Rust 1.34.0）中得到稳定。

为了确保底层硬件确实支持原子操作，这些类型具有cfg属性，例如，AtomicI8为#[cfg(target_has_atomic = "8")]，因为AtomicI16为#[cfg(target_has_atomic = "16")]etcetera。

@MatthieuM：我不明白。没有什么能阻止Rust拥有仅对保证为原子的`T`类型有效的`Atomic <T>`以及对用户的编译时检查。Rust提供的当前原子接口似乎不必要地是非通用的。 (3认同)
可能会注意到与C ++的区别，因为它实际上是通过std :: atomic <T>方式实现的。因此，它提供了一个统一的接口，但是实际上并不能保证总是使用实际的原子指令来实现“ std :: atomic <T>”。根据平台的不同，它可能会使用原子指令，也可能需要一些更复杂的技巧，例如互斥锁：这由一个“ always_lockfree”关联的常量公开。 (2认同)
是的，不是，但是那不是我要说的重点。C ++ 11在`Atomic` RFC之前5年引入了`std :: atomic <T>`。我希望使用`std :: atomic <T>`的经验以及在某些平台上使用原子指令而不是在其他平台上使用原子指令生成的代码的脚步枪，在一定程度上为对“ Atomic” RFC的“后备”提供了反馈。 (2认同)
[这是在现有类型之上进行操作的一种方法]（https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=8e9ccb32b2f7f8df3b9d538ec561cb79）。如果原本是在设计原子类型时考虑到这一点的，则可能会更清洁。我不知道为什么他们没有，但是这也不会打扰我太多。 (2认同)

归档时间：	6 年，7 月前
查看次数：	199 次
最近记录：	6 年，7 月前

为什么对于许多基本类型都存在一种“原子*”类型，而不是通用的“原子&lt;T&gt;”类型？

为什么对于许多基本类型都存在一种“原子*”类型，而不是通用的“原子<T>”类型？