multithreading - 为什么指向静态不可变变量的不可变指针不同步？

Question

静态全局 C 字符串(如 this answer )没有 Sync trait .

pub static MY_STRING: &'static *const u8
  = "hello" as const *u8;

// TODO: Simple assertion showing it's not Sync ;)

Sync 被描述为

The precise definition is: a type T is Sync if &T is thread-safe. In other words, there is no possibility of data races when passing &T references between threads.

看起来这完全是只读的并且具有静态生命周期，那么为什么传递引用不安全？

Answer 1

本章Send and Sync在 The Rustonomicon描述类型为 Send 的含义或 Sync .它提到:

• raw pointers are neither Send nor Sync (because they have no safety guards).

但这只是在回避问题；为什么不 *const T实现 Sync ？为什么安全防护装置很重要？

就在那之前，它说:

Send and Sync are also automatically derived traits. This means that, unlike every other trait, if a type is composed entirely of Send or Sync types, then it is Send or Sync. Almost all primitives are Send and Sync, and as a consequence pretty much all types you'll ever interact with are Send and Sync.

这就是原始指针既不是 Send 的关键原因。也不Sync .如果您定义了一个封装原始指针的结构，但仅将其公开为 &T或 &mut T在结构的 API 中，您是否真的确保您的结构尊重 Send 的契约(Contract)？和 Sync ？如果原始指针是 Send , 然后 Rc<T>也将是 Send默认情况下，因此它必须明确选择退出。 (在源代码中，实际上有一个明确的选择退出 Rc<T> ，但它仅用于文档目的，因为它实际上是多余的。)

[...] they're unsafe traits. This means that they are unsafe to implement, and other unsafe code can assume that they are correctly implemented.

好的，让我们回顾一下:它们实现起来不安全，但它们是自动派生的。这不是一个奇怪的组合吗？实际上，它并不像听起来那么糟糕。大多数原始类型，如 u32 , 是 Send和 Sync .简单地将原始值组合到结构或枚举中不足以取消 Send 的类型资格或 Sync .因此，您需要一个非 Send 的结构或枚举。或非 Sync在你需要写一个 unsafe impl 之前.

Send和 Sync是标记特征，这意味着它们没有方法。因此，当函数或类型放置 Send或 Sync绑定(bind)到一个类型参数上，它依赖于该类型在其所有 API 中遵守特定契约。正因为如此:

Incorrectly implementing Send or Sync can cause Undefined Behavior.