Rustは、SendやSyncといったauto traitsを導入し、すべての複合型に対して手動でスレッド安全性を証明するという負担を軽減しています。歴史的に、システムプログラマーは、各構造体に複雑な並行性契約を注釈しなければならず、これはエラーが発生しやすく冗長でした。コンパイラは、すべての構成フィールドがそれらを実装する場合に限り、集約型（構造体、列挙型、タプル）に対してこれらのトレイトを自動的に実装することにより、これを解決します。
問題は生ポインタ（*const Tおよび*mut T）にあります。参照やスマートポインタとは異なり、生ポインタはコンパイラが検証できる所有権やエイリアスセマンティクスを持ちません。生ポインタは、スレッドローカルストレージ、未割り当てメモリ、または外部同期を介して管理される共有可変状態を指すことがあります。Tのみに基づいてSendやSyncを生ポインタに盲目的に適用すると、コンパイラがスレッド境界を越えてポインタが正しく使用されていることを保証できないため、メモリ安全性が侵害されます。
解決策は導出ロジックを二分します。集約型の場合、コンパイラは構造的再帰を実行します：各フィールドをチェックします。生ポインタの場合、コンパイラはこれらの実装を明示的に保留し、それらを不透明で潜在的に安全でないハンドルとして扱います。これにより、開発者は unsafe impl Send または unsafe impl Sync を使用し、コンパイラが推測できないスレッド安全性の保証を維持する責任を負うことになります。
use std::ptr::NonNull; // 集約型 struct Container<T> { data: Vec<T>, // Vec<T>はTがSendであればSend index: usize, } // Container<T>はT: Sendの場合、自動的にSendです // 生ポインタを持つ型 struct Node<T> { value: T, next: *mut Node<T>, // 生ポインタは自動導出を破ります } // 明示的なオプトインが必要 unsafe impl<T: Send> Send for Node<T> {} unsafe impl<T: Sync> Sync for Node<T> {}
高頻度取引アプリケーションのために、ゼロアロケーションかつロックフリーのMPMC（マルチプロデューサー、マルチコンシューマー）リングバッファを開発していた際、ノードはjemallocの競合を避けるために事前に割り当てられた配列に存在する必要がありました。Node構造体にはペイロードと、侵入リストを形成する*mut Node<T>次ポインタが含まれていました。バッファハンドルをワーカースレッドに送信しようとしたところ、コンパイラはNodeがSendを実装していないためコードを拒否しました。私はノードが原子比較交換操作を介してのみアクセスされることを知っていましたが。
私は3つの解決策を評価しました。まず、生ポインタをBox<Node<T>>に置き換えることです。これは、Boxがヒープ所有権と個別の割り当てを意味するため、キャッシュフレンドリーなリングバッファを断片化し、高頻度取引では受け入れられない割り当て遅延を引き起こすため拒否されました。次に、NonNull<Node<T>>をAtomicPtrでラップして使用しました。 AtomicPtr自体はTがSendであればSendですが、含むNode構造体は依然として自動導出に失敗しました。生ポインタがNonNullの内部にあるため（これは生ポインタのラッパーです）、構造チェックがブロックされます。第三に、unsafe implブロックを使用してSendとSyncを手動で実装します。
私は、nextポインタへのすべてのアクセスが異なる状態インデックスでのSeqCst原子操作によって守られていることを正式に確認した後、3つ目のアプローチを選択し、発生前関係がデータ競合を防ぐことを保証しました。この解決策は、ロックフリーでゼロアロケーションのアーキテクチャを維持しつつ、Rustの型システムを満たしました。その結果、ミューテックスオーバーヘッドなしで毎秒数百万のイベントを処理できる生産向けのキューが実現されましたが、将来の保守者のために広範なSAFETYコメントが必要でした。
なぜSend型の生ポインタが自動的にSendを実装しないのか？
候補者は、Sendがすべてのフィールドを通じて「伝播する」と考えることがよくあります。生ポインタが本質的な所有権セマンティクスを持たないプリミティブ型であることを認識できません。コンパイラは、スレッドローカルストレージへのポインタか共有ヒープメモリへのポインタかを区別できず、エイリアスルールを検証できません。したがって、*const Tおよび*mut Tは、Tに関係なく自動的にSendまたはSyncを実装しないため、プログラマーはポインタのスレッド安全契約に責任を持つためにunsafe implを使用する必要があります。
Unsafeな内部を含むジェネリック構造体に対してSendを条件付きでどのように実装できますか？
多くの開発者は、unsafe implが無条件である必要があると考えています。実際には、「unsafe impl<T> Send for MyType<T> where T: Send + 'static {}」のように書くことができます。これは、コンテンツがSendであるときにのみSendであるべきカスタムUnsafeCellラッパーのようなジェネリックコンテナにとって不可欠です。候補者は、unsafe implのwhere句が安全トレイトと同じ表現力を持ち、スレッド安全性の制約がジェネリックコードを通じて適切に伝播し、実装を過度に制約することなく実現できることを見逃しています。
生ポインタを持つ型に対してSyncを実装するための安全要件をSendとは何が異なるのか？
Sendは、スレッド境界を越えて値の所有権を移動することが安全であることのみを要求します。生ポインタの場合、これは通常、ポインタする対象がSendである限り、アドレス値の移動が安全であることを意味します。一方、Syncは、スレッド間で不変参照（&Self）を共有することが安全であることを要求します。もし&Nodeが生ポインタ値を公開し（逆参照される可能性があります）、他のスレッドが可変参照を介してポインタが指す対象を変異させた場合、これはデータ競合を構成します。したがって、生ポインタを含む型に対するSyncの実装には、ほぼ常に同期アクセスの証明が必要です（例：ポインタはMutexの下または原子操作を介してのみアクセスされる）。一方、Sendは、独自の所有権移転の証明のみを必要とします。