ロックに伴うオーバヘッドを避ける最も単純な方法の一つは、スレッド（あるいは、カーネルの場合 CPU）ごとにデータを分けて、あるデータ部分はただ１つのスレッドによってアクセス及び更新されるようにすることです。このアプローチはとても広く使われています。実際これは、初心者でさえ、ほぼ直感的に採用する使用パターンの一つです。これがとても広く使われているため、この章では新しい例は紹介せず、以前の章の例を再使用します。 クイッククイズ８．１：C あるいは C++ で共用メモリ並列プログラムを（例えば、 pthread を使って）作成するときに、避ける事がとても難しいデータ所有の形式とはどのようなものでしょう？ データ所有には多くのアプローチがあります。８．１節はデータ所有の論理的極限を示します。そこでは、各スレッドが自分のプライベートなアドレス空間を持ちます。８．２節は逆の極限で、データは共有され、異なるスレッドが異なるアクセス権を持ちます。８．３節は関数シッピングです。これは特定のスレッドが所有するデータに他のスレッドが間接的にアクセスするのを可能とする方法です。８．４節は特定の関数と関連するデータに、どのように特定のスレッドを割り当てるかを示します。８．５節は、共用データを使うアルゴリズムをデータ所有を使うものに変換することで、性能を改善することについて議論します。最後に８．６節は、データ所有をファーストクラス市民として備えているいくつかのソフトウエア環境をリストします。
８．１ 複数プロセス
４．１節で、以下の例をあげました。
1 compute_it 1 > compute_it.1.out &
2 compute_it 2 > compute_it.2.out &
3 wait
4 cat compute_it.1.out
5 cat compute_it.2.out
この例は、compute_it プログラムの２つのインスタンスを並列に走らせます。２つの独立したプロセスは、メモリを共用しません。なので、あるプロセスの全てのデータはそのプロセスが所有します。このため、前記の例では、ほぼ全てのデータが所有されています。このアプローチは、同期オーバーヘッドをほぼ完全に除きます。この結果得られる、素晴らしい単純さと、最適な性能の組み合わせは、もちろん、とても魅力的です。
クイッククイズ８．２ ８．１節で示した例で、どのような同期がまだ残っていますか？
クイッククイズ８．３ ８．１節で示した例で、共用データはありますか？
この同じパターンは、sh だけでなく、図４．２と４．３に示したように、C で書くこともできます。 次の節は、共用メモリ並列プログラムでの、データ所有の利用を述べます。
８．２ 部分的データ所有と pthread
５章では、データ所有をたくさん使いました。が、ひねりを加えました。スレッドは、他のスレッドが所有するデータを変更することは許されませんが、それを読むことはできます。つまり、共用メモリの使用によって、より微妙な所有とアクセス権の概念が可能となりました。 例えば、５７ページの図５．９で示される、スレッドごとの統計カウンタ実装を見ましょう。ここで、inc_count() は、対応するスレッドの counter インスタンスだけを 更新しますが、 read_count() は、すべてのスレッドの counter インスタンスをアクセスします。なお、変更はしません。
クイッククイズ８．４ それぞれのスレッドが、スレッドごと変数の自分のインスタンスだけを読むことができ、他のスレッドのインスタンスに書くことができるような、部分的データ所有というのは、いったい、意味がありますか？
純粋なデータ所有は、一般的で、かつ、役に足ちます。例えば、１１１ページの、６．４．３節で述べた、スレッドごとのメモリアロケータキャッシュなど。このアルゴリズムでは、それぞれのスレッドのキャッシュは、完全に、そのスレッドにプライベートです。
８．３ 関数シッピング
前の節は、スレッドが、他のスレッドのデータに手が届く、データ所有の弱い形式を述べました。これは、データを、それを必要とする関数に届けると考えることができます。その代わりとなるアプローチは、関数をデータに送ることです。 ７４ページの５．４．３節に、そのアプローチが示されています。特に、７６ページの図５．２４の、flush_local_count_sig() と flush_local_count() 関数です。 flush_local_count_sig() 関数はシグナルハンドラで、送られた関数としてはたらきます。flush_local_count() の pthread_kill() 関数がシグナルを送り（関数をシップします）、送った関数が実行するのを待ちます。この送られた関数は、当然、全ての同時実行する、add_count() や sub_count() （７７ページの図５．２５と７８ページの図５．２６）と相互作用する必要があるという、余分な複雑さを持ちます。
クイッククイズ８．５ 関数シッピングに、POSIX シグナル以外の機構を使うことができますか？
８．４ 専用スレッド
これまでの節は、それぞれのスレッドが、データの自分専用のコピーあるいは、自分専用の部分を持つことを許す方法を述べてきました。それに対して、この節は、機能分割アプローチを述べます。ここでは、特別の専用スレッドが、自分の仕事をするために必要なデータへの権利を持ちます。５．２．３節で述べた、結果整合カウンタ実装が、その例です。この実装は、図５．８の１５から３２行目で示す、eventual() 関数を走らせる専用のスレッドを持ちます。eventual() スレッドは、定期的に、スレッドごとのカウントをグローバルなカウンタに吸い上げ、グローバルなカウンタへのアクセスが、名前のとおり、最終的には、実際の値に収束するようにします。
クイッククイズ８．６ でも、図５．８の１５から３２行目で示す、eventual() 関数のデータは、実際にはどれも、eventual() スレッドが所有していません！いったいどんな理由で、これがデータ所有なのですか？？？
８．５ プライベート化
共用メモリ並列プログラムの性能とスケーラビリティを改善する１つの方法は、共用データを特定のスレッドが所有するプライベートデータに変換することです。 この優れた例は、６．１．１節のクイッククイズの一つの答えにあります。そこでは、食事をする哲学者問題の答えを作るのに、プライベート化を使っています。そこでは、標準的な教科書の解答よりずっと良い性能とスケーラビリティが得られます。元の問題は、５人の哲学者がテーブルの周りにいて、哲学者の隣り合う対に１つのフォークがあります。このため、同時に最大２人の哲学者が食事ができます。 この問題をプライベート化するのは自明で、追加で５つのフォークを提供すれば良いです。そうすれば、哲学者は彼あるいは彼女のプライベートなフォークの対を持つことができます。これにより、全ての５人の哲学者は同時に食事ができますし、ある種の病気が蔓延することもありません。 他の場合には、プライベート化はコストを要求します。例えば、６２ページの図５．１２に示した単純な限界カウンタを見ましょう。これは、スレッドが、お互いのデータを読むことができるが、自分自身のデータだけを更新できるアルゴリズムの例です。アルゴリズムを簡単にレビューすると、スレッドをクロスするアクセスは、read_count() の合計ループだけにあることがわかります。もしこのループを除ければ、より効率的な純粋データ所有に移れますが、read_count() の結果はより不正確となるコストを払います。
クイッククイズ８．７ スレッドごとのデータの完全なプライバシーを保ちながら、より良い正確さを得ることは可能ですか？
つまり、プライベート化は並列プログラマの道具箱で強力なツールです。しかし、それだからこそ、注意して使わなくてはいけません。他の全ての同期プリミティブと同じように、複雑さを増し、性能とスケーラビリティを落とす潜在性を持ちます。
訳注。性能を増すけど、複雑になる。の方が、文脈で自然。
８．６ データ所有の他の使い方
データ所有は、データが分割できて、スレッドをクロスするアクセスや更新の必要が少しあるいは全くないときに最もうまくはたらきます。幸運にも、この状況は、十分に一般的で、並列プログラミング環境の広い領域で有効です。 データ所有の例は：
１ MPI や BOINC のような、メッセージパッシング環境の全て。
２ マップリデュース。
３ クライアントサーバシステム。これには、RPC, ウェブサービス、そして、バックエンドデータベースサーバーを持つとても多くの任意のシステムを含みます。
４ シェアードナッシングのデータベースシステム。
５ プロセスごとのアドレス空間を持つ、 fork-join システム。
６ Erlang 言語のような、プロセスベースの並列化。
７ プライベート変数。例えば、スレッド環境の C 言語のスタック上 auto 変数。
データ所有は、たぶん、存在する同期機構の中で、最も正当な評価がされていないものです。 正しく使えば、他にない単純性、性能そしてスケーラビリティが得られます。たぶん、それがあまりに単純なので、見合う尊敬を得られないのかもしれません。データ所有の巧みさと力がもっと評価され、より良い性能、スケーラビリティ、そして複雑さの削減につながることは言うまでもなく、より大きなレベルの尊敬を得られるようになることを祈ります。
以上