歴史的に、RustはArc（原子参照カウント）に対するパフォーマンス重視の代替としてRc（参照カウント）を導入しました。言語の初期バージョンではこの区別がなく、すべての共有所有権が原子操作のコストを負担しなければなりませんでした。SendおよびSync自動トレイツは、スレッドセーフな構成を強制するために設計されており、コンパイラは型の構成要素に基づいてこれらのプロパティを自動的に導出できます。
根本的な問題は、Rcの内部実装にあります。これは通常、Cell<usize>またはUnsafeCell<usize>にラップされた非原子カウンタを使用してアクティブな参照を追跡します。この設計は、メモリバリアのオーバーヘッドを回避するために単一スレッドでのアクセスを前提としています。もしRc<T>がSendを実装できるとしたら、プログラムはポインタのクローンを異なるスレッドに移動させることができます。新しいスレッドでの破棄またはクローンの際に、両方のスレッドが参照カウントに対して非同期に読み取り-修正-書き込み操作を行うことになり、これがデータ競合を引き起こし、カウントが破損する可能性があります。これにより、早期解放（use-after-free）やメモリリーク（double-free）が発生する恐れがあります。
解決策はアーキテクチャにあります：Rcは、スレッドセーフでない型を含むことで、明示的にSendとSyncから除外されています（または、現代のRustでのネガティブ実装を介して）。これにより、開発者はクロススレッド共有のためにArc<T>を使用する必要があり、これはそのカウンタにAtomicUsizeを使用しているため、インクリメントおよびデクリメント操作が原子的であり、すべてのCPUコアで正しくシーケンスされることが保証されます。コンパイラは型レベルでこの区別を強制し、ランタイムチェックなしでの偶発的な共有を防ぎます。
大型文書を抽象構文木（AST）に解析する高性能テキストエディタを考えてみましょう。パーサーは、木全体で共有される部分文字列（例えば、同一の識別子）を表現するためにRc<Node>を使用しており、単一スレッドの解析フェーズ中にメモリを最適化しています。セマンティックバリデーションを並行処理するために、サブツリーをスレッドプールに分配する必要があります。
即座の問題は、Rc<Node>をワーカースレッドに送信しようとするとコンパイルが失敗することです。いくつかの解決策が評価されました：
Arcでのグローバル置換：すべてのRcインスタンスをArcに置き換えること。利点：最小限のコード変更で即時のスレッドセーフさ。欠点：プロファイリングの結果、ホットパスでの不必要な原子操作により解析中のスループットが12-15%低下し、パフォーマンス予算を違反しました。
送信のための深いクローン：サブツリーをVec<u8>にシリアライズし、バイトを送信し、ワーカーでデシリアライズすること。利点：Unsafeコードやアーキテクチャの変更が不要です。欠点：内部サイクルを持つ複雑なグラフ構造のマーシャリングによる高い待機時間とCPUコストが発生し、リアルタイム編集には負担となります。
Unsafeポインタ抽出：Rcを生ポインタに変換し、ポインタを送信し、受信側でRcを再構築すること。利点：ゼロコピーオーバーヘッド。欠点：根本的に安全でなく、Rcの所有権不変条件を侵害します（受信スレッドは送信スレッドがクローンをドロップするかどうかを知ることができず）、必然的にメモリの破損やダングリングポインタを引き起こします。
チャネルベースのタスクディスパッチ：メインスレッドでASTを保持し、軽量なバリデーションタスク（バイト範囲やノードインデックス）をcrossbeamチャネルを介して送信します。ワーカーはRcで管理されたメモリに触れることなく結果を返します。利点：解析のためのRcパフォーマンスを保持し、Unsafeなしでデータ競合を排除し、コンポーネントを分離します。欠点：バリデーションアルゴリズムをデータ並列からタスク並列に再構築する必要があります。
チームはチャネルベースのアプローチを選択しました。パーサーは単一スレッドで高速のままであり、バリデーションはコア数に線形にスケールしました。その結果、Unsafeブロックのない安定したシステムが確立され、パフォーマンス特性が維持されました。
なぜRc**<T>は、ラップされた型TがSyncであっても、Syncではないままなのか、またこれはSend制限とどう異なるのか？**
Rc<T>はSyncであることはできません。なぜなら、イミュータブルリファレンス（&Rc<T>）は**.clone()を呼び出すことができ、内部の非原子参照カウントを変更するからです。たとえT自身が共有するのが安全であっても（Sync）、スレッド間でRc**ラッパーを共有すると、複数のスレッドからカウンタを同時にインクリメントすることが可能になり、データ競合を引き起こします。Send制限は、所有権を別のスレッドに移動することを完全に防ぎ、一方、Sync制限は、スレッド間でのリファレンスの共有をさえ阻止します。Rcは、内部の変異を実行する「読み取り専用」操作（クローン）を行うため、これらの原則の両方を侵害します。
カスタム構造体が生ポインタ(*const T)をラップする場合、PhantomData<T>がSendおよびSyncの自動導出にどのように影響し、その包括がなぜ重要であるか？
PhantomDataなしでは、*const Tを含む構造体には、オートトレイト導出の目的でTにリンクする型情報がありません。コンパイラは、ポインタがダングリングするか、恣意的にエイリアスを持つか、スレッドローカルデータを指す可能性があるため、SendまたはSyncを推論できません。PhantomData<T>を含めることで、開発者はその構造体が論理的にTを所有していることをコンパイラに通知します。その結果、T: Sendの場合、構造体は自動的にSendを実装し、T: Syncの場合、Syncを自動的に実装し、FFIラッパーやカスタムスマートポインタに必要な構成可能なスレッドセーフを復元します。
特定の条件下で、トレイトオブジェクトBox**<dyn Trait>が、基となる具体的な型がSendを実装していても、このSend自動トレイトを失うのはなぜか？**
トレイトオブジェクトdyn Traitは、トレイトの定義が明示的にSendをスーパー境界として要求する場合にのみSendを実装します（例えば、トレイトTrait: Send）。具体的な型をトレイトオブジェクトに消去する際、コンパイラはオートトレイトの実装を含むすべての特定の型情報を破棄します。トレイト自身がSend性を保証しない限り、コンパイラはvtableがスレッドセーフなメソッドを指していることを確認できません。これにより、スレッド間のボックス化されたトレイトオブジェクトを送信することができなくなり、トレイト境界が明示的にSend（およびSync）を含む場合に限り、オブジェクトの安全性がスレッドセーフな実装に制限されます。